> 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).
That's nice when someone is working for you. In this case I believe there
were multiple bugs, and the viable choices were to ship with the old known
bugs or do testing on the new version until it is accepted as tested.
Given that the release schedule seems to be measures in generations these
days, shipping a driver known to be bad is probably worse than doing one
more rc and asking people to beat hell out of the driver.
>
> > 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.
I bet your release schedule is more frequent, too. There comes a time when
doing a whole new QA is better than trying to be sure a fix works without
doing full QA anyway. As in both faster and more likely to result in a
correct result.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/