On Thu, Feb 14, 2013 at 12:05:01PM -0800, Greg Kroah-Hartman wrote: > On Thu, Feb 14, 2013 at 01:55:12PM -0600, Ben Myers wrote: > > > Ok, how about I never apply any xfs stable kernel patch, unless you send > > > it to stable@xxxxxxxxxxxxxxx? > > > > Dave has made it clear that he doesn't want to be involved in maintaining > > -stable kernels. I don't think you quite understand, Ben. It is obvious from the fact that this discussion is taking place that I'm extremely concerned about the quality of -stable kernels and what goes into them. What I think you are missing is that there is a difference between not having the time to do the grunt work of backporting and testing -stable kernels versus wanting to ensure the quality of the maintenance work that does take place remains high. Why do I say this? Because the responsiblity of maintaining XFS development is not SGI's. It is a community effort, and I am as much responsible as anyone else. Someone else doing a half-arsed job maintaining XFS in -stable kernels reflects badly on *me* as being a senior member of a community that allows it's members to do a half-arsed job on something. > > However, my team at SGI is interested in maintaining -stable > > kernels. Then do the job properly. Being "interested" isn't enough - you need the *commitment* to ensure things are done properly. If you *personally* don't have the the time to ensure that the -stable kernel maintenance is done properly, then don't do it at all. > > We're not going to use the fact that there is a risk of regression as > > an excuse to starve -stable of relevant fixes, just as we do not use it as an > > excuse to starve the upstream branch of feature content. I'm not complaining because there is a risk of regression in -stable backports, I'm pointing out that our long-standing process used to minimise that risk was not followed. Besides, -stable backports are all about risk management. The primary consideration for a backport is whether the risk of regressions is higher than the risk of leaving the bug unfixed. We've NACKed lots of proposed patches for -stable simply because the risk of regression outweighes the benefit to users of -stable inclusion. Yes, there is always a risk of unintended regressions, but you have to do *due diligence* on the backports to -stable trees to minimise the risk factor. Even the most basic "apply the patch, run xfstests" check would have found this regression. So, even if we ignore the risk factors here, a *preventable regression* occurred because due diligence was not performed correctly on the requested patch. BTW, Ben, I should point out that 6 months ago you said exactly the opposite to this statement - you tried to use "risk of regressions" as an excuse to starve the dev tree of new feature content. i.e. you wanted to apply -stable tree criteria to the -dev tree. Now you are saying that risk of regression is not a reason for rejection for the -stable tree. (i.e. applying -dev tree criteria to the -stable tree). IMO, you are as wrong about the -stable tree now as you were about the -dev tree 6 months ago.... > > > I have that rule in place for some other subsystems that don't want me > > > applying stuff that they aren't aware of, and have no problem doing the same > > > thing here. > > > > > > Just let me know. Sounds like a fine idea, Greg. > > Here are the usual suspects: > > > > Ben Myers <bpm@xxxxxxx> > > Mark Tinguely <tinguely@xxxxxxx> > > Dave Chinner <dchinner@xxxxxxxxxx> > > Eric Sandeen <sandeen@xxxxxxxxxx> I don't think it should be restricted to individuals. The private thread used to request this backport is exactly why I didn't see the request in a timely fashion, and also the reason why we didn't end up with notifications for review going to xfs@xxxxxxxxxxx. Hence I'd suggest the only thing that matters is that there is a cc to xfs@xxxxxxxxxxx, because that means all of the above people (and more) are on that list and hence have the best chance to see and review the backport request. > Ok, but for this specific patch, did I do something wrong in taking it? No, you didn't do anything wrong, Greg. Stuff went wrong on the XFS side of the fence. > I guess I'll just let you send me xfs patches, is that ok with everyone > else? Sure, that would work, but only after the patches have been sent to xfs@xxxxxxxxxxx for review and testing and been acked. And, of course, the stable submission woul dalso need to have a xfs@xxxxxxxxxxx cc on it. ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
