[lkml]   [2012]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ 00/78] 3.3.2-stable review
    On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <> wrote:
    > On 12 April 2012 09:49, Felipe Contreras <> wrote:
    >>> A revert is the same as a patch.  It needs to be in Linus's tree before
    >>> I can add it to the stable releases.
    >> Right, because otherwise people's systems would actually work.
    >> But hey, as I said, following rules is more important, regardless of
    >> what the rules are, and why they are there. The rules that actually
    >> triggered this issue in v3.3.1, as this is not in v3.3.
    >> You could just accept that the patch should have never landed in
    >> v3.3.1 in the first place, but it's much easier to arbitrarily keep
    >> stacking patches without thinking too much about them.
    > Greg is doing the right thing here. We face the same deal in FreeBSD -
    > people want fixes to go into a release branch first, but if you do
    > that you break the development flow - which is "stuff goes into -HEAD
    > and is then backported to the release branches."
    > If you don't do this, you risk having people do (more, all)
    > development and testing on a release branch and never test -HEAD (or
    > "upstream linux" here). Once you open that particular flood gate, it's
    > hard to close.

    But this is exactly the opposite; the patch that broke things is in
    the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
    also on a later upstream, which is also broken.

    But then are you saying that if upstream is broken (3.4-rc2), then
    stable should be broken as well (3.3.1), and remain broken until
    upstream is fixed? I fail to see what would be the point of that.

    > We had this problem with Squid. People ran and developed on Squid-2.4.
    > The head version of Squid-2 was stable, but that isn't what people ran
    > in production. They wanted features and bugfixes against Squid-2.2,
    > squid-2.4, and not Squid-2.STABLE (which at the time was
    > Squid-2.6/Sqiud-2.7.) That .. didn't work. Things diverged quite
    > quickly and it got very ugly.

    And why do you think the same would happen here if *one patch* is applied?

    Plus, git is developed this way; and yes, you might say the gates are
    opened when there's a new non-maintenance release, but the same
    happens in Linux. It's not the rule of 'first on X' branch that keeps
    the gates safe; it's the amount of patches.

    > So I applaud Greg for sticking to correct stable release engineering
    > here. We over in the BSD world know just how painful that is. :)

    So, in your mind "correct" is "never ever do an exception", even if
    this strictness leads to less stability. If the objective is not
    stability, I would call this the 'backports' tree then, which might or
    might not lead to stability.

    Rules are not perfect, why not add a new rule "It reverts an earlier
    patch to 'stable'.", then you would be both following the rules, and
    ensuring more stability :)


    Felipe Contreras
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-04-12 20:45    [W:0.023 / U:13.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site