linux-kernel - Re: Slow DOWN, please!!!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c0942db0805010829r50ea361ja9e62a33991dc640@mail.gmail.com>
Date:	Thu, 1 May 2008 08:29:18 -0700
From:	"Ray Lee" <ray-lk@...rabbit.org>
To:	"Bartlomiej Zolnierkiewicz" <bzolnier@...il.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, "Willy Tarreau" <w@....eu>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"David Miller" <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Jiri Slaby" <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!

On Thu, May 1, 2008 at 6:16 AM, Bartlomiej Zolnierkiewicz
<bzolnier@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/