This is the mail archive of the
mailing list for the GDB project.
5.0 post mortem
- To: GDB Discussion <gdb at sourceware dot cygnus dot com>
- Subject: 5.0 post mortem
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 05 Jun 2000 12:56:25 +1000
- Organization: Cygnus Solutions
(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
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
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
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
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
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
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
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,