lkml.org 
[lkml]   [2008]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.


\
 
 \ /
  Last update: 2008-05-01 17:31    [W:0.375 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site