I agree with Martijn's view on the first release of a podling which is much more critical than subsequent releases.
But for subsequent releases the voting process should be simplified in one way or the other. At the moment we have to get approval from our Mentors first before we can move to the IPMC and this can take quite a long time. Getting people not directly involved in the development process to vote on a release candidate is not always easy. Hence my opinion is: -1 for the first release +1 for subsequent releases Rainer Martijn Dashorst wrote: > Re: [DISCUSS] Changing poddling release voting process > > -1 > > I try to check my podlings' releases personally, but I usually fail > where Sebb shines :). It is much easier to guide the addition of new > committers/ppmc members than it is to properly vet a *first* release. > > The first release of any podling is an exercise of patience and > frustration, but it does bring a better understanding of the > importance of releasing, and how to vet releases. After a release has > been performed, scrutinized and torn apart by general@, all subsequent > releases are usually a walk in the park. > > I also agree with Thilo that having these things on general@ is a good > thing and try to instruct my podlings to subscribe to general@ so they > can learn from others' misfortunes. > > Martijn > > On Fri, Aug 21, 2009 at 8:58 AM, ant elder<ant.el...@gmail.com> wrote: > > What do people think about changing the poddling release voting > > process so that there is just a single vote which is held on the > > poddlings dev list instead of the dual voting we have now with a > > poddling dev list vote followed by an general@ vote? This would be > > similar to the changes done recently for committer and PPMC votes > > which removed the dual voting and help empower the poddlings. There > > would of course still be the minimum requirement of 3 +1s from IPMC > > members, and a notification process so the IPMC is fully aware of the > > vote. Can work out the details of that later in a formal doc change > > proposal but first I'd like to see if there's much support for or > > against such a change? > > > > ...ant > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.4 increases type safety for web applications > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
