2013/11/28 sebb <seb...@gmail.com> > On 28 November 2013 08:05, Thomas Neidhart <thomas.neidh...@gmail.com> > wrote: > > On 11/28/2013 04:09 AM, Damjan Jovanovic wrote: > >> Vote closed, results were: > >> > >> +1: > >> Damjan Jovanovic > >> > >> No other votes were cast. > >> > >> Vote fails since majority approval needs at least 3 votes of +1 -> > >> aborting release. > > > > Hi Damjan, > > > > sorry that this vote failed, and I hope you still continue with this > > release, I will at least review your next RC! > > > > @all: something that bothered me while doing the release for collections > > 4 and I have seen too for this component: > > > > While a vote is being cast, people other than the RM should restrain > > themselves from making changes to trunk. Even if the intention is just > > to help the RM and clean up things, such an action is usually quite > > detrimental to the vote itself. > > I think that depends on the scale of the changes. > If there is a simple typo or change to the website, then it's more > effort to save the changes for later (and so they may get lost). > But I agree that large cosmetic changes should probably be left to > later (or perhaps be done in a branch). >
This sounds like a job for git to me :) > > > So I propose the following: > > > > * cast your vote with suggestions for improvement > > * compile your changes as patch and either attach them to an issue > > or send them to the RM > > > > After the vote has ended or cancelled the changes can be included, but > > just changing trunk during a vote has the following effect: > > > > * gives other people the impression that the vote will fail anyway > > thus postponing their vote for the next RC > > * putting pressure on the RM to cancel the vote as already many > > changes have been made to the trunk, even if they are purely of > > cosmetic nature > > > > Imho, cosmetic or style related changes should *never* block a release. > > +1 > > > These are things that can be worked on between releases, so we can > > really focus on the important things during the release procedure. > > > > If things are not perfect, just make another release a month later that > > tidies up all the source code. We always say: release early, release > > often, but in fact we never do that, the credo is always: release > perfect. > > The problem here is that an imperfect API can cause long-term problems. > > This means that the first release of an component is bound to take > longer as there is lots to review. > Subsequent releases should be easier as only the API changes need to be > reviewed > > == > > Another aspect to release votes is that sometimes the first RC is sent > for a vote without any advance warning. > Unless others have been following the dev list very closely the RC > vote can be the first time that others have got to review the code. > Thus the RC vote may bring out lots of comments on the API. > I agree that reviews should also be done on individual commits, but if > a component is undergoing lots of changes, it won't always be clear > when it has stabilised. So again if the first RC generates lots of > changes it would be helpful to give advance notice of the next RC. > > > Thomas > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
