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). > 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
