[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [VOTE] Release Imaging 1.0 from RC7
From:       Phil Steitz <phil.steitz () gmail ! com>
Date:       2013-11-29 17:04:05
Message-ID: 5298C905.60607 () gmail ! com
[Download RAW message or body]

On 11/28/13, 12:22 PM, Oliver Heger wrote:
>
> Am 28.11.2013 09:05, schrieb Thomas Neidhart:
>> 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.
> Yes, I second that. For me commits on a component that is currently
> voted for a release have the effect you described. I am confused whether
> it makes sense to review and vote as it seems that the vote is going to
> fail anyway.

I appreciate the sentiment here.  Personally, it doesn't bother me
if I am RM other than this phenomenon of people not reviewing /
voting once a few commits have been made to trunk.  I agree with
Sebb that giving some advance warning that an RC is about to be cut
can help some.  We used to have a much more formal process where RMs
were "elected" via lazy consensus and release plans were documented
on the Wiki.  I don't think we need to go back to that level of
formalism, but I think we should agree to at least post a note
indicating that an RC is imminent based on trunk plus whatever WIP /
JIRAs the RM has in mind for inclusion.  And then those of us who
are going to review and vote on the release commit to looking at the
code and surfacing issues before the RC count gets painful for the
RM.  I would be OK using JIRAs with patches during RC cycles if that
makes things easier.  That does create a little extra work for the
RM though and when that is me I would prefer to just get the stuff
committed directly into trunk.

Another thing that will help is to try to get to "comment early,
comment often" or allow the do-ocracy to proceed.  We have lots of
great eyeballs here; but its actually better to get a smaller number
of us looking deeply at the code early than lots of people surfacing
nits late.

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


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

[prev in list] [next in list] [prev in thread] [next in thread]