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. > 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 ? 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). But again, I fail to see improvement in doing this - as long as we agree on testing seriously before voting. - René --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
