What I dislike is spending untold personal hours fixing all known issues and putting out a release, only to have it continually shot down, not available to anyone. Specifically:
1. Our release plan states we only make GA's available on the mirrors and from the download page, so anything less is hidden from view and unavailable for users 2. The betas we do put out are poorly tested by the PMC 3. The fact that all this "testing" happens after the release. This is completely backward! After every release, you will find issues with it down the road. By holding the voting and "testing" till after the release is rolled, chances are you will find something you don't like resulting in a failed vote. This is very discouraging for the Release Manager who put hours into creating the release. The icing on the cake is out of all the complaints of the DTD bug, none of the people who took the time to write detailed explanations bothered to lift a finger to fix it (Wendy finally did), much less roll another release. I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were 2. Do all testing and even the vote _before_ a code freeze and subsequent release. I personally won't waste my time doing a release if people will only test it after the fact. Don On 5/16/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
I hadn't made a point of responding since the vote was already closed, but I've come to agree that the problems identified with the 1.3.4 build are sufficient to make it a "beta", and further, I've just identified one or two other things that are worth nothing that probably further justify that. Before listing them, I'll note that I now agree that it is wrong to call a vote on a release's quality offering the choices of "alpha," "beta," or "GA". Rather, we should have straight "yes/no" votes for each of these in turn, perhaps at a prescribed interim. I would be willing to forego always requiring an "alpha" vote, but it seems like we should never vote a release "GA" that hasn't had a decent period of use as a "beta" release. Some of us who have been using Struts 1.3 are confident in it, but we don't constitute a big enough population to be the only beta testers. I understand Don's frustration at the lack of people participating in testing, but I think that we would get more people testing if we put something out and called it a beta than simply expecting them to test nightly builds and test builds. Committers should be checking test builds and finding the kinds of packaging things that were uncovered with Struts 1.3.3, but it takes more time to uncover other things, and more testers. I've uncovered a couple of things in porting an old Struts 1.1 application to 1.3; I know they probably need to go in Jira, but I wanted to get a little discussion about them before filing them. Actually, now I think i'll send them separately with different subject lines to help manage the various conversations that might arise... Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
