Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of thomas.neidhart@gmail.com
 designates 74.125.82.171 as permitted sender)
Message-ID: <5296F93C.6070804@gmail.com>
Date: Thu, 28 Nov 2013 09:05:16 +0100
From: Thomas Neidhart <thomas.neidhart@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [VOTE] Release Imaging 1.0 from RC7
References: 
 <CAJm2B-khDCxvWzS8gQJYiRTJPktA_KKa=iXuLtZQRaDUXWu8+Q@mail.gmail.com>
 <CAJm2B-=t=gh29KXz+LRK+aRZV8ib0ywKd1cpHvgrOMHTD-hpCg@mail.gmail.com>
In-Reply-To: 
 <CAJm2B-=t=gh29KXz+LRK+aRZV8ib0ywKd1cpHvgrOMHTD-hpCg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org