[lkml]   [2011]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/7] Nexus One Support
    On Sat, Jan 22, 2011 at 01:18:54PM +0200, Pekka Enberg wrote:
    > Why is that? I don't see any technical problem of upstreaming the
    > original patches even if they don't compile (as long as they're not
    > included in Makefiles or Kconfig files). There's no need to hide the
    > real history even if it looks ugly...

    I've asked Daniel in private whether he'd mind posting the original
    set of patches which he based his work on to this thread.

    I suspect that the situation is that there's many patches which he's
    taken from the repository and consolidated them down into a nice set
    of easy to review patches.

    One of the problems of preserving the micro-detail of history right
    from the early inception of support for a platform is that quite often
    the early support is buggy or broken - it might not even compile. There
    may be 20 or so patches on top of that which eventually get it to a
    usable state.

    Do we really want to put off people from reviewing patches because of
    the size of micro-development that happened prior to getting to a point
    where the result of that development is usable?

    Tell me this: does a patch which cleanly adds support for board X get
    reviewed by more, the same, or less people than a set of twenty patches
    which goes about the same thing, adding code, removing previously added
    code, changing it again.

    I personally _hate_ patch sets which do that, and I tend to ignore them
    (or maybe review the first twenty patches before taking a break... and
    then never going back to them) because I quickly get tired reading all
    that code - which means I'm not able to do an effective review. I
    suspect most people suffer from reviewer tiredness when faced with large
    patch sets changing the same code time and time again.

    I personally believe that Daniel is doing the right thing here, except
    he needs to preserve a better record of authorship. I even think it's
    fine if he decides to drop people's sign-offs if he thinks the code has
    changed significantly from the original authors - provided he's willing
    to take responsibility for the submission of that code.

    If you read what a sign-off means (the DCO) then it's clear that if the
    code has changed significantly, the original sign-offs do not apply
    anymore - the original sign-offs can't warrant that the modified code
    is covered by appropriate licenses or even that the person who modified
    their code has the rights to submit it.

    Take a moment to think about that. If I took some of your code with
    your sign-off, changed it significantly by including someone elses work
    where there were no rights to submit that persons work into mainline,
    and I kept your sign-off on that, would you be happy when someone starts
    making accusations against you submitting their code?

    The sign-offs make no representation of who was the author. In many
    cases where companies are involved, the first sign-off is the person
    who authorized the release of the code, not the person who wrote the
    code, so it's a complete mistake to attribute authorship by whoever was
    listed first in the Sign-off lines. Authorship may be jointly held by
    the first 4 people listed, and attributing authorship to only the first
    is just as bad as not attributing authorship at all.

    Lastly, from the arguments being made over this, if they are supported,
    I think that people are saying that the actions listed in DCO (b) are
    no longer allowed, and so DCO (b) should be removed entirely as an
    acceptable practice. IOW, what's being promoted as "you must do" (iow,
    preserving all history) is completely contary to the allowances of
    DCO (b).

     \ /
      Last update: 2011-01-22 13:23    [W:0.022 / U:51.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site