On Thu, Oct 1, 2009 at 10:50 PM, Wes Wannemacher <w...@wantii.com> wrote:
> 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.
Ditto. I am also OK either way in this situation.
> 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.
First, let me be clear. I am *not* advocating for slowing down the
rate at which we put out releases. I am all for "release early,
release often".
What I would argue against, though, is the notion that collapsing the
cycle we previously had (announce a build, allow some time for people
to check it out, call a vote and decide whether it is GA or beta or
should stay just a test build and not be a release at all) into a
single step ("here is it, quick, is it GA?") meaningfully slows down
the process. Unless you're on a tear and releasing a new expected-GA
release every week to two, using our previous release mechanics does
*not* significantly slow down the process, and does have significant
potential for increasing the confidence in the quality that we end up
assigning to that build.
> 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!).
To some extent, I agree. We do need to encourage participation. The
only caveats are that we have to assume that people interested in
helping with Struts development are reading the dev list (that is, we
cannot enlist the user list population in testing pre-release code),
and, in my opinion, we should have a high degree of confidence when we
label something as GA, since that has significant implications for our
users.
> 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.
Some portions of the timing are part of the ASF process (e.g. votes
being open for 72 hours) that we must abide by. Others, such as
announcing a test build and allowing some time before starting a vote,
are for us to decide. As I said above, I am happy for us to move
quickly. But I also believe that we can move quickly without rushing.
--
Martin Cooper
> -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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
