[parisc-linux] Re: Version 0.9 of PA-RISC Linux Released

[Alan Cox]

> On Tue, Jun 05, 2001 at 03:22:20PM -0500, Michael S. Zick wrote:
> > The only way to validate a change as a potential patch is:
> > 1) start with a clean (error and warning free) build that
> > boots and runs on the machine of interest.
> > 2) hack, change, modify, whatever
> > 3) when done, make another clean build that boots and runs
> > on the machine of interest.
> > 4) evaluate the effects of the change(s).
> > 5) If successful - then you MIGHT have something worth
> > submitting as a POTENTIAL patch.
> > Exactly the same 5 steps your developers take before they
> > commit a change to CVS.
> 
> the people with CVS access are hardly `my' developers.  and the process
> you describe is only one form of development.  it's not applicable in a lot
> of cases.

A lot of the Linux development occurs on much more of a 'directed chaos'
approach, and that's an approach gaining favour in software engineering 
circles too. If it looks roughly right you throw it in or run it past someone
with a good eye for code in that area and throw it in. If as is normally the
case the patch is fine it works very efficiently. When the patch turns out to
be wrong it is rare that there are multiple patches likely to cause the reported
symptoms.

Also you can run continual automated testing using tools like cerberus. Yes
my Software Engineering lecturer would never have approved - but it works.

Alan