Re: Aix7xxx unstable in 2.4.21-rc2? (RE: Linux 2.4.21-rc2)

[James Bottomley <James.Bottomley@steeleye.com>]

On Sat, 2003-05-24 at 02:43, Willy Tarreau wrote:
> > I think there's some misunderstanding about what a release candidate
> > is.  It's an attempt to see if a particular set of code is viable as the
> > released product.  Any bugs reported against a rc that are deemed
> > problems to the release need to be fixed, either by adding a simple and
> > easily verifiable bug fix or by reverting the problem code.
> 
> That's also my point. People were reporting problems till -rc1 which included
> driver version 6.2.28. So Marcelo reverted to 6.2.8 for -rc2 (74500 lines of
> code reverted, not including doc nor aic79xx which was kept). Then, people were
> still reporting problems with -rc2 which they claim are fixed by updating
> to last driver updates, which were 16000 lines forward from -rc1, so less than
> one fourth of what Marcelo accepted to change from -rc1 to -rc2. Although I
> find this big, it's less than the change in fusion/mpt* that has gone from
> -rc2 to -rc3. So I think it's not a matter of size here.

It is a question of size and provenance.  Alan Cox descriped the mpt
fusion update as "assorted small fixes" and deletions exceed additions
in the patch set by 40%.  It's also about user base:  aic7xxx is by far
the most widely used SCSI chip, I'm not sure how many 2.4 fusion users
there are but I speculate its probably orders of magnitude fewer.

> Most of this is a 1 MB Changelog, files going back to their original place
> (Marcelo moved aic79xx to a proper directory to keep it), documentation, and
> initialization code which was exploded in more little functions, then bug fixes.

The argument isn't about size, it's about safety.  No company that wants
to stay in business accepts code into release stabilisation unless it's
clearly justifiable.  Trying to buck the system by including five
features plus one critical bug fix is one of the oldest tricks in the
Software Engineers book---do this and you get hauled before the release
committee whose job will be to pare the addition back to just the bug
fix (and send you away with a flea in your ear to boot).

> I wish Justin would have proposed a little patch to fix only the locking bugs
> in -rc1, but honnestly, why should he fix only these bugs when he knows about
> others that must be fixed too ? I can understand he gives up. -rc is for bug
> fixes, and his bug fixes are reverted !

Marcelo reacted exactly as the release committee would at Adaptec:
either provide the bug fix for assessment or we'll push it out into the
next release.  This is industry standard practice, so I don't see any
problem.

> As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
> as a priority. The current pre-releases are as frequent and as big as what
> used to be full releases in the past.

I agree.  One of the necessary things for a fast release is a good
release manager (and thus one prepared to make unpopular decisions--and
ones you don't necessarily agree with).

James