For multiple votes it seems that in general people will look at a
release and stop at the first problem. So, other problems that can
be addressed aren't noted until the next re-spin as I think most
people stop looking when the first issue is reported.
The other problem is not many people seem to be testing the server.
Aaron is the one who reports the lion's share of the problems (and
yes, I despise him for it ;-0 ) But, he is finding legitimate
problems in actually using the server. I don't believe many people
have time to do more than pull the server, start it and poke around
the binaries.
The third issue are problems people know of but haven't had a chance
to document and remember as the release is going out. Generally
after its built ;-(
Another problem with the last release was that we had to co-release
specs as well as redo the way we create our XMLBeans classes for the
J2EE schemas.
One of the ways of improving the process is having more people work
on releasing the server so they get an appreciation of the time drain
there is. There are a lot of moving parts and releasing the specs,
new schemas and Geronimo didn't help.
We also had some issues with Jacc where fixes were committed to the
wrong branch :)
Does that help ?
On Sep 21, 2006, at 3:59 AM, Alan D. Cabrera wrote:
Matt,
I want to thank you for all the work you done over the past
releases. I'm wondering if you could pass some wisdom on to the
new generation of fool hardy release managers.
I have one question, for now. ;) What, in your opinion causes
multiple release votes? I can understand there being multiple
release candidates but in the last case, I think that there were
four polls taken for what was supposed to be the final release. Do
you have any advice?
Regards,
Alan
Matt Hogstrom
[EMAIL PROTECTED]
