[1.7] bugs in faccessat
Wed Sep 9 13:24:00 GMT 2009
Christopher Faylor wrote:
> On Tue, Sep 08, 2009 at 09:16:57PM +0200, Corinna Vinschen wrote:
>> On Sep 7 16:05, Christopher Faylor wrote:
>>> On Thu, Sep 03, 2009 at 11:04:38PM +0200, Corinna Vinschen wrote:
>>>> Thanks for the patches Eric, but, here's a problem. We still have no
>>>> copyright assignment in place from you. The fcntl patch is barely
>>>> trivial, but the faccessat patch certainly isn't anymore. Would it
>>>> be a big problem for you to send the filled out copyright assignemnt form
>>> >from http://cygwin.com/assign.txt to Red Hat ASAP? With any luck it
>>>> will have arrived and will be signed before I'm back from vacation.
>>> I don't understand why this isn't considered trivial but a basically
>>> equivalent change to fix other errnos is:
>> It's 2 vs. 30 lines of changes. That's hardly equivalent.
> But each of those changes were obvious and each could have been
> contributed separately, one for every function. That would have
> made them trivial.
There's no simple answer to this, it seems. On the one hand(*), the GNU
maintainers' handbook suggests that multiple trivial patches /can/ over time
add up to a substantial contribution(**):
> A change of just a few lines (less than 15 or so) is not legally
> significant for copyright. A regular series of repeated changes, such as
> renaming a symbol, is not legally significant even if the symbol has to be
> renamed in many places. Keep in mind, however, that a series of minor
> changes by the same person can add up to a significant contribution. What
> counts is the total contribution of the person; it is irrelevant which
> parts of it were contributed when.
On the other hand, for example, in accord with the second sentence of that
paragraph, binutils just accepted a *huge* patch without an assignment - but
it was completely mechanical (renaming symbols to avoid c++ compilation
errors). There's going to be a big gray area in between this kind of trivial,
potentially-automatable mechanical replacement that is obviously OK and the
level of a patch with (e.g.) a big bunch of new functions or code that is
obviously not OK (without an assignment). I'm not sure where this patch
falls, except to say that it's in there somewhere. I think I'd be inclined to
accept it if anyone argued that the repeated cutting-and-pasting of the
set_errno hunk was one change with some mechanical repetition and counted it
as only five lines.
(*) - disclaimer: Cygwin is of course a RedHat project and so need not operate
to the same standards as the FSF holds to; examples are only examples and not
represented as definitive, canonical, or legally binding; contents may have
settled in shipping or packing; YMMV, IANALATEIHSMBSI, fnord!
(**) - http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
More information about the Cygwin-patches