5.0 post mortem

[Andrew Cagney <ac131313 at cygnus dot com>]

(FWIW, I don't know what happened to the gnu.announce posting - I
definitly submitted it :-)

Well before a 5.0.1 or 5.1 release is started its probably worth having
a bit of a post-mortem (where the vultures can pick over the bones of
what happened :-)  Here are my random thoughts:


	o	feature based not date based release criteria

		First lesson I learnt was that people don't
		like releases made on the basis of an arbitrary
		date.

		Instead the consensus was that a set of features
		should be identified and the release should be
		made once those features were included.

		In the end there was some give and take over
		what was in/out of the list.  Given the size
		of the backlog from the previous release I think
		what we ended up with was pretty reasonable.
		Things that were dropped were either dropped
		because they had no active developer or because
		the problem was too difficult/complex for the
		expected time frame.


	o	must have VS nice to have VS won't have

		Once consequence of the first point was that
		I ended up maintaining (using the TODO file!)
		three separate lists.

		In doing this, I tried to avoid the situtation
		where people were only allowed to work on
		``must have items''.  If I had tried to do that
		I think development would have simply stagnated.
		Instead I tried to categorize the feature list
		based on those three criteria.  They would then
		be moved depending on what I perceved as the
		current reality.  I figured ``must have'' wasn't
		much use if no one was willing to work on it.
		Besides, if someone implemented a ``might have''
		or ``won't have'' who am I to argue :-)

		I tried to apply the ``won't have'' where I felt
		that there was more benefit in getting the work
		into the follow on release than trying to squeeze
		it into the current release.  As a category,
		``won't have'' is only going to work if there are
		regular releases and people can build up confidence
		in it.

		I don't know what people think of me using the TODO
		list as the tracking mechanism.  I also don't
		know what people thought of my fairly abitrary
		(at times) re-aranging of the three lists.


	o	I need to remember to use the gdb-testers mailing list

		When putting up release candidates I need to
		remember to post them to gdb-testers (which
		has a different audience to gdb-patches and
		the like).  On more than one occasion I simply
		forgot.


	o	A better way of tracking test results

		I tried using the TODO file for that however
		I don't think it was very successful.  Having
		public test farms like netwinder.org are probably
		a step in the right direction. (I just wish they
		would include the test results on the main page
		so I didn't have to download that summary.log :-)

		I'm fairly skeptical towards idea's that involve
		people maintaining pages by hand.


	o	I think the branch timing was about right

		Comparing the changes made to the trunk/branch,
		I think, in the end, the 5.0 branch was
		cut at about the right time.

		The emphasis was on getting the 5.0 feature
		list resolved (fixed or discarded) and then
		cutting the branch.


	o	we need more tests

		The old perennial.  There are never too many
		tests.

		My personal opinion is that, once the branch,
		has been cut it is almost too late to try
		to fix bugs the test suite is identifying.
		Instead they should be documented.  The emphasis
		should instead be put on keeping the trunk
		in good condition so it can be branched at
		any time.


	o	give that final release candidate ~7 days

		For those that don't know, I received
		e-mail of a djgpp problem just after I'd
		put the final release on sourceware but
		before gnu.org.


	o	ftp.gnu.org is first not last

		Following on from the above, get the
		final release candidate onto ftp.gnu.org
		first not last.  That way the cut off date
		is extended.


	o	the mechanics worked

		The mechanical process of spinning a release
		worked without a hitch - the nightly build is
		using it (and hence testing it).

nice day for it,

	Andrew