If we can't get the help from people in the user list, then I would
say we do what you are suggesting, but we take it to the "extreme" a
bit, meaning, that when we think the code is ready to be frozen for a
release, we cut a build(with tag, staging repo and all) and let people
in dev@ know about it, then a month later or so, whenever we feel like
it is pretty decent to assume we are in the clear, we can call a vote
on it. I think that's would give us more confidence in what we are
voting for.
musachy
On Fri, Oct 2, 2009 at 9:14 AM, Martin Cooper <mart...@apache.org> wrote:
> 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
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
