flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: [VOTE] Allow RC votes to carry over at any point in the release process
Date Fri, 05 Dec 2014 19:22:14 GMT
On Fri, Dec 5, 2014 at 11:11 AM, Rich Bowen <rbowen@rcbowen.com> wrote:

> On 12/05/2014 07:59 AM, Justin Mclean wrote:
>> Being the RM and making a release has a legal responsibility. I don't
>> think we should be forcing the RM to be doing anything that has potential
>> legal issues.  The incident that this VOTE has arisen from was about
>> changing NOTICE and then making a release without the required PMC
>> oversight and that certainly fits into this (slightly scary) category.
> Although I don't have a vote here, as an ASF member I have to agree with
> Justin's assessment here.
> Given that a release only requires 3 +1 votes, it shouldn't be a hardship
> to vote again. Having a vote "carry over" only seems to make sense if,
> indeed, nothing changed. If something changes, it's reasonable to ask
> people to have a look before they vote.

This is again a case of misleading characterization of the issue in hand.
We have already in the past, voted to allow 'carry over' of votes for
minor, non-code related changes.

Justin, when he was RM refused to carry over votes in spite of

a.) making a non-code related change
b.) the voters explicitly asking him to carry over their votes (One of them
was me.  Properly testing that artifact would take hours.  I know that
nothing in the code changed, so I did not want to retest the entire
package.  Hence my request to carry over the previous vote)

The RM refused to carry over the votes by raising a technical loophole that
he did not mention that votes were carried over when he called the vote for
that RC.  He could have simply started a new RC email voting thread, but he
refused to do that too.

All this current vote does is remove that loophole.

Nothing much to discuss here, we are trying to take a vote so that we don't
needlessly spend time discussing this loophole that only one person wants
to invoke.  We want to move on.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message