lkml.org 
[lkml]   [2012]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ 00/78] 3.3.2-stable review
    On Apr 14 Felipe Contreras wrote:
    > I already exemplified how they are very different, but here it goes
    > again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
    > was just tagged in 3.3.2, if I had said yesterday "this patch breaks
    > things on my machine", then that patch would have been dropped for
    > 3.3.2 even though it's still on mainline--why? Because we know it's
    > broken, and broken patches are not supposed to land to stable. But
    > today, one day later, we have to wait until it's fixed in master
    > first. Why?
    >
    > What makes a patch droppable yesterday, but dependent on mainline today?

    Huh?

    Because "yesterday" was a review before stable release:
    - A buggy mainline release exists.
    - No buggy stable release exists.
    whereas "today" is after stable release:
    - A buggy mainline release exists.
    - A buggy stable release exists.

    (The WLAN breakage wich is being talked about was reported after
    release, not during review, right?)

    [quote re-ordered]
    > Again, you can repeat the same thing as much as you want, it still
    > doesn't answer what I have asked.

    Yeah, sorry for that. All the time I thought you asked why a *revert*
    which is applicable to mainline and stable first happens in stable.

    But your question was actually what the difference between
    - dropping a patch from a queue of candidate patches versus
    - adding a reverting patch to repair a defect from a previous release
    is.

    The former is still part of the decision whether a changeset which
    exists in mainline should be backported into stable. Somebody initially
    thought it should be, but others should have a look too and amend that
    decision if need be. Somebody reports that the change would introduce a
    regression. Usually, this disqualifies a patch from being applied to
    stable right away, without further work having to be done in stable.

    "Drop a stable candidate before release" is a form of "decline a
    submission to stable", happening late in the preparations of a stable
    release.

    The latter is when damage was done; it is now about bug fixing. This
    involves debugging of the regression, finding a right approach to
    fix it (e.g. revert), write + review + test + commit the fix, port the fix
    to all relevant other kernel branches, review + test + commit those ports
    too.

    "Add a reverting fix" is a form of "add a fix".

    You are indeed pointing to a procedural flaw here. In "add a fix" cases,
    stable release procedures ensure that if 3.3.3 included the revert, 3.4
    will include it to, by the Linus->Greg order of commiting patches. But in
    the "drop a candidate before release" case, Greg and the stable reviewers
    do not have a similarly fool-proof procedure to ensure that the next branch
    point will be free of the regression. Now they need to watch closely that
    a fix gets into mainline ideally before the next branch point is going to
    be released.

    So there is indeed a difficulty involved with dropping patches from the
    candidate queue. Fortunately, it is not necessary to subject post-release
    reverts to the same difficulty.

    > This of course, has *not* been explained.

    Others had discussed "not adding a changeset" versus "amending an already
    released changeset by another changeset on top of it" already. Now I did
    too and apologize to everybody else for redundancy.
    --
    Stefan Richter
    -=====-===-- -=-- -===-
    http://arcgraph.de/sr/


    \
     
     \ /
      Last update: 2012-04-14 09:45    [W:0.023 / U:0.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site