linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	torvalds@linux-foundation.org, gregkh@linuxfoundation.org,
	lists@uece.net, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, akpm@linux-foundation.org,
	alan@lxorguk.ukuu.org.uk, linux-wireless@vger.kernel.org,
	c_manoha@qca.qualcomm.com, ath9k-devel@venema.h4ckr.net,
	linville@tuxdriver.com
Subject: Re: [ 00/78] 3.3.2-stable review
Date: Fri, 13 Apr 2012 07:34:16 +0200	[thread overview]
Message-ID: <20120413053416.GC12807@1wt.eu> (raw)
In-Reply-To: <CAMP44s26eJ6mFHt=C+_AJCkGiDAcMq1O1HsCXPZd5-FRYkZoXQ@mail.gmail.com>

On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
> > From: Felipe Contreras <felipe.contreras@gmail.com>
> > Date: Fri, 13 Apr 2012 01:04:42 +0300
> >
> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
> >> 'stable' material, and removing it does not affect upstream at all.
> >
> > What you don't understand is that bug fixes will get lost if you only
> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable.
> 
> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
> would you have fond out there was an issue with it? There's 10000
> patches in v3.4-rc2, how do you expect to find issues in them?
> 
> People found out this issue on v3.4-rc1, so the fix would not have
> been lost, but lets assume it would, v3.3.1 had the issue, the patch
> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
> already 10000 patches that would never make it to 3.3.x, and many will
> have issues, which is why there would be v3.4.x.
> 
> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
> > that got fixed in -stable a time long ago when we didn't have the
> > policy we're using now which you're going so unreasonably ape-shit
> > about.
> 
> I see how a *fix* on stable could get lost, but this is not a fix.

Felipe, you don't seem to get it : there are many bugs in each new release.
Given the number of fixes Greg merges into a longterm branch, I'd say that
there are around 1500 bugs waiting to be discovered and fixed in a new
release. Does this mean we need to fix them all at once ? No, because we
don't know about them yet.

The process you're criticizing consists in ensuring that once a bug is known,
it gets fixed in mainline so that it never appears there again. The way the
bug is discovered doesn't matter, even if it's discovered that a fix caused
the bug and that it must be reverted. The fact is mainline is buggy and we
know this because stable is too. So mainline must be fixed first. This
process works because stable users are pressuring developers to push their
fixes to Linus in order to get them. What happened with this bug prooved
the process is working fine.

Another point is that you don't want stable to merge, revert, merge again,
revert again etc... This happened a little bit during 2.6.32 because some
fixes were not really obvious. It's common for some fixes to have to be
adapted for stable branches, and to have side effects, hence the review
cycle. We need to limit these random issues as much as possible if we
don't want users to lose trust in the stable branches. This is extremely
important. So picking random fixes that have not been qualified by all
interested parties in stable is inappropriate. Reverting without evaluating
impacts is one form of picking a random fix.

What you should have done would have been to reply to Greg saying "wait a
minute, we still have an issue with patch XX, I'm trying to get it reverted
in upstream and will send you the commit ID, it would be nice to have it in
3.3.2". It wastes less time for everyone and achieves the same result.

Once again, if you think that the stable branch you're using is not stable
enough for you, pick another one. Greg maintains multiple branches so that
everyone is satisfied. The risk of bugs over time probably looks like
(cos(t)+1)/t. Find an older branch with a much smaller risk of regressions
and be done with it.

Last point, you should note that you're the only one here who doesn't
understand the process. That doesn't make you a fool, but it should tell you
that you probably need to think a bit further before telling people how they
should work, especially when all other ones agree on the benefits of the
process, including Arnd explaining that FreeBSD had been facing the exact
same trouble and now applies the same process. It is not just a small band
of nerds doing this for fun right here, but seems to be more generalized.

Regards
Willy


  reply	other threads:[~2012-04-13  5:34 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120411231102.GA6404@kroah.com>
2012-04-11 23:59 ` [ 00/78] 3.3.2-stable review Sergio Correia
2012-04-12  0:29   ` Greg KH
2012-04-12  0:57     ` Sergio Correia
2012-04-12  1:03     ` Felipe Contreras
2012-04-12  1:13       ` Greg KH
2012-04-12 13:32         ` Felipe Contreras
2012-04-12 14:46           ` Greg KH
2012-04-12 16:49             ` Felipe Contreras
2012-04-12 17:24               ` Adrian Chadd
2012-04-12 18:43                 ` Felipe Contreras
2012-04-12 18:56                   ` Jonathan Nieder
2012-04-12 21:34                     ` Felipe Contreras
2012-04-12 21:43                       ` Willy Tarreau
2012-04-12 20:07                   ` Greg KH
2012-04-12 20:52                     ` Sven-Haegar Koch
2012-04-13  8:57                   ` Stefan Richter
2012-04-13 10:29                     ` Felipe Contreras
2012-04-13 13:42                       ` Stefan Richter
2012-04-13 14:01                         ` Stefan Richter
2012-04-13 22:38                         ` Felipe Contreras
2012-04-13 23:05                           ` Jonathan Nieder
2012-04-13 23:18                             ` Felipe Contreras
2012-04-14  5:44                               ` Willy Tarreau
2012-04-14 15:43                                 ` Felipe Contreras
2012-04-14 16:02                                   ` Willy Tarreau
2012-04-14  9:10                               ` Stefan Richter
2012-04-14 15:52                                 ` Felipe Contreras
2012-04-14 18:08                                   ` Stefan Richter
2012-04-14  7:41                           ` Stefan Richter
2012-04-14 15:29                             ` Felipe Contreras
2012-04-14 15:57                               ` Willy Tarreau
2012-04-14 19:33                                 ` Felipe Contreras
2012-04-14 19:58                                   ` Willy Tarreau
2012-04-14 17:55                               ` Stefan Richter
2012-04-14 19:21                                 ` Felipe Contreras
2012-04-14 21:21                                   ` Stefan Richter
2012-04-14 22:09                                     ` Felipe Contreras
2012-04-14 22:47                                       ` Stefan Richter
2012-04-14 22:56                                         ` Felipe Contreras
2012-04-14 23:06                                           ` Adrian Chadd
2012-04-13 19:08                       ` [ath9k-devel] " Peter Stuge
2012-04-13 22:53                         ` Felipe Contreras
2012-04-14  6:01                           ` Willy Tarreau
2012-04-16 16:27                           ` Greg KH
2012-04-16 20:11                             ` Felipe Contreras
2012-04-16 20:58                               ` Greg KH
2012-04-16 21:18                                 ` Felipe Contreras
2012-04-16 21:27                                   ` Greg KH
2012-04-16 21:44                                     ` Felipe Contreras
2012-04-16 22:34                                       ` Peter Stuge
2012-04-17  5:24                                       ` Willy Tarreau
2012-04-16 21:50                                     ` Felipe Contreras
2012-04-16 21:54                                       ` Don deJuan
2012-04-16 22:02                                       ` Don deJuan
2012-04-16 21:39                                   ` Don deJuan
2012-04-12 18:40               ` Willy Tarreau
2012-04-12 19:05               ` Linus Torvalds
2012-04-12 21:20                 ` Felipe Contreras
2012-04-12 21:34                   ` Linus Torvalds
2012-04-12 21:44                     ` Linus Torvalds
2012-04-12 22:02                       ` [ath9k-devel] " Luis R. Rodriguez
2012-04-12 22:04                     ` Felipe Contreras
2012-04-12 22:07                       ` Linus Torvalds
2012-04-12 22:29                         ` Felipe Contreras
2012-04-14 10:47                           ` Ingo Molnar
2012-04-14 15:59                             ` Felipe Contreras
2012-04-15  6:51                               ` Ingo Molnar
2012-04-15 17:15                                 ` Felipe Contreras
2012-04-15 17:29                                   ` Willy Tarreau
2012-04-15 17:49                                   ` Linus Torvalds
2012-04-15 22:12                                     ` Felipe Contreras
2012-04-16  5:32                                       ` Ingo Molnar
2012-04-16 20:25                                         ` Felipe Contreras
2012-04-16 21:08                                           ` Arend van Spriel
2012-04-16  5:39                                       ` Willy Tarreau
2012-04-16  6:38                                         ` Ingo Molnar
2012-04-12 22:12                       ` David Miller
2012-04-12 22:58                         ` Felipe Contreras
2012-04-13  5:34                           ` Willy Tarreau [this message]
2012-04-13 10:04                             ` Felipe Contreras
2012-04-12 21:39                   ` Willy Tarreau
2012-04-12 22:02                   ` Jesper Juhl
2012-04-12 19:57     ` Alexander Holler
2012-04-12 20:06       ` Greg KH
2012-04-12 20:30         ` Alexander Holler
2012-04-12 22:31           ` Greg KH
2012-04-12  4:16   ` Heinz Diehl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120413053416.GC12807@1wt.eu \
    --to=w@1wt.eu \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ath9k-devel@venema.h4ckr.net \
    --cc=c_manoha@qca.qualcomm.com \
    --cc=davem@davemloft.net \
    --cc=felipe.contreras@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=lists@uece.net \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).