On releasing

[Egbert Eich]

Adam Jackson writes:
 > On Tuesday 18 April 2006 13:12, Egbert Eich wrote:
 > > Adam Jackson writes:
 > >  > If this is ever the case (and it is), you're not releasing often enough.
 > >  > Wasn't "release early and often" the _mantra_ for modularization?
 > >
 > > Well, before you do a release you still need some people to test your stuff
 > > - don't you? The more there are the more secure you are that what you
 > > release is really OK.
 > > Looks like you are advocating snapshot releases. Release and forget as soon
 > > as the next one comes out.
 > 
 > I want to defuse this particular point.  Remember that our version numbers are 
 > multivariant.  Major, minor, bugfix, buildfix, if you want to split it that 
 > far down.  It may well be that the first usable 1.5.x version of the i810 
 > driver is 1.5.4.  That's just the way it goes.  It doesn't mean you should 
 > hold off from releasing 1.5.0 until you're sure it's perfect.

I don't think we are in contradition here.

 > 
 > You _will_ ship with bugs.  We always have and we always will.  Accept that 
 > reality and design your processes to reflect it.  For most modules, this 
 > means release for almost any user-visible change and okay yeah your version 
 > number will get large in the last digit, so what.

People wdo appreciate if versions they pull have received sufficient 
soak time before they are declared to be a release. Nobody will expect
anything to be entirely free of bugs.

Furthermore if you realease a module you must expect that people pull 
it and report bugs on it. This may happen half a year or longer down 
the road.
The more often you release the harder it will be to keep track which
problem has been fixed when - or tell them not to bother to report bugs
unless they have pulled the latest release.

I know that the argument held against this is that people should get
bits from their 'Linux vendor' - which is expected to have given them
soak time and picks up the QA work.
There are two points to this:
1. It supports the argument that vendors have a strong interest
   to cherry pick fixes from SCM.
2. The world lis not commercial +  Linux vendors only.
   Leaving the QA process almost entirely to downstream may cause 
   problems to other communities. Maybe I'm wrong here. Somebody
   from the BSDs should probably comment here.

 > 
 > I am absolutely not advocating snapshot-and-forget in the general case.
 > 
 > Now for the server, which has a pretty high rate of churn, I think regular 
 > snapshots are valuable, in that they give a quick and relatively fine-grained 
 > way of stating when bugs or features were introduced.  The level of 
 > integration testing required for a releasable server is generally higher than 
 > that for the leaves of the module tree, so longer release cycles with 
 > mostly-usable snapshots is probably a better choice than me stamping out 
 > 1.1.0 today and waiting for the bug reports to come flying back in.

Right.

 > 
 > Point is: pick a process and go with it, as long as it gets code released in a 
 > fashion that's timely, or predictable, or both.

Our QA 'guidelines' seem to be very much in the flux as pretty much 
everything else. At least I don't seem to completely understand them.

Depending on who you ask you get different opinions (which may also 
change over time). 

Cheers,	    
	    Egbert.