On Thu, Dec 06, 2012 at 11:27:22AM -0600, Mark Tinguely wrote: > On 12/05/12 15:45, Dave Chinner wrote: > >On Mon, Dec 03, 2012 at 05:42:08PM -0600, Mark Tinguely wrote: > >>Here a collection of bug fixes for 3.0-stable. Many of these patches > >>were also selected by Dave Chinner as possible 3.0-stable patches: > >> http://oss.sgi.com/archives/xfs/2012-08/msg00255.html > >> > >>I chose only bug fixes and kept the changes to a minimum. > >> > >>Patch 21/22 are required for the bug fix in patch 23 but they are > >>important changes in their own right. > > > >So I'll ask the same question that Christoph asked me: If nobody is > >reporting problems on 3.0.x, why do this and risk regression and > >fallout that requires fixing? > > > >FWIW, what testing have you done? > > Do you mean? > > http://oss.sgi.com/archives/xfs/2012-09/msg00002.html > > I read that message as a concern that your original Linux 3.0-stable > patch series contained some items that did not meet the -stable > criteria. I read it as "why change something that no-one is reporting bugs for?". I posted that series because I had to do the work for RHEL to address customer reported problems, not because I felt like pushing a bunch of fixes back to 3.0. I've spent quite a bit of time over the past few weeks dealing with various weird regressions as a result of that backport. If you're going to backport a singificant amount of stuff to 3.0.x, then that's what you are signing up for. i.e. doing all the bug triage and fixing that will result from the backport... > As for adding patches to 3.0-stable. I believed then and now that > proactively suggesting bug fixes into 3.0-stable is a good thing > because it is the long term stable branch. Which is in direct contrast to what most of us think. That is, if nobody is reporting problems, then it ain't broke and it doesn't need fixing. > A few days after Christoph's email, I put my "Reviewed-by:" on your > series. > > http://oss.sgi.com/archives/xfs/2012-09/msg00167.html > > As for testing, the whole series is spun on xfstests loops for days on > x86_32 and x86_64 boxes, just like we test a top of tree patch series. Which we all know does not catch all possible regressions. What about crash/shutdown testing? Or load/stress testing? /me is playing Devil's Advocate because I'm not signing up to triage a whole new set of 3.0.x stable kernel regressions when nobody is currently reporting problems..... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
