Messages in this thread | | | Date | Thu, 1 May 2008 08:29:18 -0700 | From | "Ray Lee" <> | Subject | Re: Slow DOWN, please!!! |
| |
On Thu, May 1, 2008 at 6:16 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote: > > On Thursday 01 May 2008, Rafael J. Wysocki wrote: > > How about: > > > > (1) Merge a couple of trees at a time (one tree at a time would be ideal, but > > that's impossible due to the total number of trees). > > (2) After (1) give testers some time to report problems introduced by the > > merge. > > (3) Wait until the most urgent problems are resolved. Revert the offending > > changes if there's no solution within given time. > > (4) Repeat for another couple of trees. > > (5) Arrange things so that every tree gets merged once every two months. > > > > This would also give us an idea of which trees introduce more problems. > > ...and what would you do with such information? [...] > Same goes for any other kind of improvement by incorporating "punishment" as > the part of the process.
When a teacher assigns grades in a class, it's not punishment, it's feedback.
I don't think anyone *intends* to push crap into the tree. However, with the barrier to getting things into the tree so low, some may feel there's less incentive to try to get things right the first (or second) time. It would be nice to provide that incentive.
Normally, it'd be peer-review of the uncommitted patches. We don't have a lot of that going on here, though. So, peer-review-after-the-fact, ie, who placed this massive turd in the tree, and everyone swivels an eye over there and asks what went wrong, and how do we prevent it in the future. Those conversations seem to be happening already, time to time.
And as a policy suggestion, if we're past rc1 and someone has identified a commit as the root of a regression/bug, then the policy should be just to revert it immediately, no questions asked. Let the original author work with the person who identified the problem and resend a fixed commit later. We lose testers in the meantime, and perhaps the extra effort involved in having the author work out the issues and redo the patch will help prevent drive-by patching in the future.
| |