On Sun, Dec 18, 2011 at 1:58 PM, Rene Gielen <rene.gie...@googlemail.com> wrote: > Hi, > > I'm both commenting on Martin's and Lukasz' mail - see inline > > On 18.12.11 22:35, Łukasz Lenart wrote: >> I've moved the discussion to the new thread as to not mismatch two >> different topics >> >> 2011/12/17 Martin Cooper <mart...@apache.org>: >>>> As a follow up, I've added one more point to the Release guide [1], is >>>> it enough ? >>> That looks fine, as long as everyone is in agreement. >>> >>> The question in my earlier message was just that - a question. The >>> answer, after digging around in the archives, appears to be yes, we >>> did stop doing that, quite some time ago, and somehow I never noticed >>> until now. As far as I can tell, we didn't make a conscious decision >>> to change; it just happened one time when somebody took on the release >>> task. Nobody noticed, and we've kept doing it that way ever since. > I cannot _remember_ that being a policy either, so without further > digging I am quite sure we're doing this for a long time now. I think > nobody noticed since our votes tended to be very lazy. It was not > unusual to have a vote casted without getting enough binding votes for > three weeks or more. >>> As for which way we do it going forward, it really depends on how >>> quickly people - PMC members especially, but not only PMC members - >>> feel they can test a new build. It is *very* important that people >>> vote, and test prior to it, based on the actual bits posted by the RM; >>> not their own build, or a recent snapshot they may have downloaded. If >>> enough people believe they can pick up a new build immediately, >>> incorporate it into their own environment, test it thoroughly, and >>> then vote, all within 72 hours, then there shouldn't be a problem with >>> continuing the way we have been. If that seems a bit tight, then we >>> should leave some time for testing before calling the vote. > I agree that taking the time for *thouroughly* testing the *actual > binary bits* is essential - everybody needs to remind that. Nevertheless > I would not see any improvement in splitting the process into a "Asking > for feedback"- and a voting-phase. The voting template is designed for > giving feedback on the build quality. If we however feel that 72h is not > enough, we might want to extend the period.
That's fine too, as long as people know what to expect, and have an opportunity to chime in. What we want to avoid is something like "here's a build; vote now; done" before the people who care about it have a chance to even see the start of the thread. Not everyone can drop everything to try out a new build as soon as it's announced, and not everyone can read the list every day to ensure they don't miss a chance to participate in the process and test a build prior to release. >> I'm wondering how to proceed to release BETA1, BETA2, ..., RC1, RC2, >> ...., GA versions. With the current approach the name of packages must >> be specified during running mvn release:prepare command, even if we >> decide to call it Beta during a Vote it isn't possible to rename the >> artifacts, Subversion Tag and so on. And to meet the result of the >> Vote, a new mvn release:prepare command must be issued and a new Vote >> called (as we vote over the exact bits) - the whole release process >> must be started over. >> >> Do I miss something ? The build you post as an RM - the build that people download, test, and vote upon - is a test build; it's not a release yet. The vote is a vote on the quality of that test build. Depending upon the result of the vote, those bits may become a GA, Beta or Alpha release, or may not become a release at all. (Note that we do not have RC releases.) Regardless of the result of the vote, the version number doesn't change; only the designation changes. > We would in either case stick with clear and unchanged versioning and > single builds, even when introducing a testing phase before casting the > vote. So we would have announced 2.3.1 as test build, and if no clear > objections arose, cast a vote for exactly this binary to become GA or > not. So essentially, the difference for the release manager is one more > mail (announcing the test build) and some more patience (before casting > the vote). Exactly. My question was solely about the waiting period that we used to have (yes, some time ago) between announcing the availability of the test build and the start of a vote to determine the quality of that test build. > But again, I fail to see improvement in doing this - as long as we agree > on testing seriously before voting. Right. And as long as the process is inclusive of those who wish to participate in the testing and quality determination. -- Martin Cooper > - René > > --------------------------------------------------------------------- > 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
