On Sat, Apr 14, 2012 at 8:44 AM, Willy Tarreau <w@xxxxxx> wrote: > Nobody has said it's perfect. Jonathan said it's "close" to perfect. I > personally think it's the best tradeoff we could find between a perfectly > stable branch and a perfect mainline. We manage to converge towards the > best quality in both branches by accepting a small delay in -stable. You are saying the same thing; it cannot be improved. > The problem is that *you* don't accept to wait as soon as you know there's > a bug, I'm going to stop right here. You are making an eloquent argument for something nobody is saying. This is pure straw man argumentation, see the reply from Stefan Richter, who seems to be the only person who is actually following the argument I'm making. > Reverting patches that were not appropriate for -stable happens from > time to time, but only when the issue is specific to -stable (eg: build > issues). Here what you don't seem to understand is that the bug was > not specific to -stable but was present everywhere. So we had a bug > in mainline that we put in -stable, and we want mainline to be fixed > and we use -stable as a guarantee that mainline will be fixed. And it > works and has never failed yet. That's not hard to understand I think. I understand you use 'stable' as guarantee, and I know it works, but do you *need* this guarantee? And before you go on why you need this guarantee to avoid fixes to be lost, this is an *entirely different thing*; we are not talking about fixes in 'stable' that don't exist in mainline--for which there is evidence that those caused problems in the past, we are talking about reverting patches from 'stable' that are not part of the upstream release from where the 'stable' branch was forked--*nobody* has showed any evidence that this has happened before and caused issues. Only Stefan Richter is trying to tackle this argument. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
