On Fri, Oct 2, 2009 at 1:25 AM, Martin Cooper <mart...@apache.org> wrote: > On Thu, Oct 1, 2009 at 10:00 PM, Musachy Barroso <musa...@gmail.com> wrote: >> I still don't understand why we don't let users know that there is a >> build that we are testing so we get more eyes on it, before we call it >> a GA. Is there any practical reason? or is it just the way it has >> always been done? > > It is supposed to be posted as a test build on the dev list only, for > exactly that purpose. It doesn't get posted to the user list because > it's not a release until it's voted on, and only releases are intended > for use by users (as opposed to developers). > > One thing that seems to have changed is that the RM is sending out > only a single message, combining the "here it is" and the "vote" > messages into one. We used to send out one message to the dev list > saying that the build was available, and then some number of days > later, start a vote thread, assuming the build had not been shown to > be bad in the meantime. Check out the dev list archives and you'll see > what I mean. > > It seems to me that it would be good to go back to that two-stage > process. The only reason I can recall for moving away from it was that > some people wanted to get releases out faster, and didn't like the > delay caused by waiting for a few days before starting the vote. > Frankly I think that rushing releases is just not worth it if they end > up having to be retracted later because of problems. (That does not do > anything for our image as a quality framework either, if we keep > having to pull releases that we originally claimed were GA quality.) >
First, I thought the consensus was that we weren't pulling this release. Personally, I could go either way. On one hand, the docs zip is bad, but on the other hand, we have been sitting on well over 100 closed JIRAs. Which brings me to my second point. I think just as much or more damage is done by not performing releases in a timely fashion. I would like to get closer to the 'release early, release often' agile style. I can see your point Martin, and I'm not necessarily arguing against it, but we do need to meet somewhere in the middle and get bugfixes out to our users. I'll wager anyone that there are more messages that include "the fix is in trunk" than there have been GA releases pulled. That being said, I get the feeling sometimes that we waste a lot of time over-analyzing. I think people are scared to contribute because they are worried about screwing things up. I enjoy working on this stuff and I enjoy using Struts, but I think we need to foster more participation with the users (I mean, they are java devs too!). I will stick to whatever waiting periods for votes, etc. but I personally want to see things move a little faster and I'm trying pretty hard to encourage that by example. I think it's much more productive to concentrate on moving forward than it is to add more discussions/feedback each time we hit a glitch. The last two builds (2.1.7 & 2.1.8) have been broken because of environmental problems, not code. My gut reaction is that this is due to our release process and release mechanics growing out of control. Doing a release includes quite a few artifacts and as we found out this time, it is not near as robustly automated as it needs to be. -Wes -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
