[1.7] bugs in faccessat

Dave Korn dave.korn.cygwin@googlemail.com
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:
>>>
>>> http://cygwin.com/ml/cygwin/2009-09/msg00178.html
>> 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.

    cheers,
      DaveK
-- 
(*) - 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 mailing list