You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/12/04 09:05:59 UTC
[TTH] vetoes get in the way
Hi,
I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
and I think allowing vetoes for most everything, as those guidelines
do, is calling for trouble.
The standard Apache voting process [1] specifies vetoes for commits only.
My recommendation would be to make those guidelines much simpler by
keeping just two voting modes as per [1]:
a) Majority approval,
http://www.apache.org/foundation/glossary.html#MajorityApproval
b) Lazy consensus,
http://www.apache.org/foundation/glossary.html#LazyConsensus (and move
to majority approval if there's a -1 there)
With c) possible vetoes for commits as per [1] - those must have a
clear technical justification to be considered valid.
And where a) applies to almost everything, and b) saves time while
allowing to move to a) if someone requests it with a -1.
Removing the right to veto allows things to move forward, driven by
the majority. It's no fun being in the minority, so in my experience
over time people learn to adapt their proposals to make them
acceptable, or make things more modular to cope with different views
of the world.
Again, you don't want to vote on each and every nitpick, but voting is
a useful tool to avoid endless discussions on things that have various
levels of importance for various people.
-Bertrand
[1] http://www.apache.org/foundation/voting.html
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 4, 2014 at 10:48 AM, Tom Chiverton <tc...@extravision.com> wrote:
> ...I'm sure if we got
> to the point of voting on something, and there were a large fraction of -1
> (but more +1) we'd still take that as a signal to evaluate whatever it was
> more strongly...
That would be great, yes. And even a single -1 might trigger your
community health alarms, but with majority approval that doesn't block
things and you can move forward while hopefully keeping those alarms
in mind.
-Bertrand
Re: [TTH] vetoes get in the way
Posted by Tom Chiverton <tc...@extravision.com>.
Reducing the types of votes available would make getting my head around
them easier, certainly.
I think the 'lazy consensus' we have listed on our Wiki also conflicts
with the Apache version because of the -1 veto, which should certainly
be corrected; we should just link to the Apache page therefore.
Code changes by (Apache) lazy are already veto-able so it's just a small
change there.
Moving everything else from consensus to majority allows more stuff to
be approved more easily, which drives the project forward. I'm sure if
we got to the point of voting on something, and there were a large
fraction of -1 (but more +1) we'd still take that as a signal to
evaluate whatever it was more strongly.
Tom
Re: [TTH] vetoes get in the way
Posted by Chris Martin <wi...@gmail.com>.
I'm on board with this. I like the idea of taking "the edge off" a -1 vote
On Thu, Dec 4, 2014 at 6:47 AM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> On Thu, Dec 4, 2014 at 9:14 AM, Harbs <ha...@gmail.com> wrote:
> > ...If you feel it should be changed anyway, I have no objections to
> that...
>
> I havent checked if allowing vetoes for many things has caused
> problems or not so far but I see a potential for creating blocking
> problems, so fixing that now is probably a good idea.
>
> -Bertrand
>
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> For some context, the reason our guidelines require consensus for adding
> people is because of this document [1]
And also was inline with other project Guidelines we looked at.[1]
We actually relaxed some of the HTTP projects guidelines ie only PMC members can veto code changes (we allow committers as well).
Thanks,
Justin
[1] eg http://hadoop.apache.org/bylaws.html
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
None of the links you provided describe anything to do with how a progression towards a release should work. It only described the release process itself. Nor do they describe how discussions should work. (Not should they.)
I’m not sure what these “several bits” that you refer to are. The one thing you mention (i.e. trying to have a single thread) is not a deviation from anything that I could see being that DISCUSS threads are not covered in the links you provided at all.
I’m willing to accept that you might not understand what others are trying to say. It would be most productive if you would ask for clarification on things that don’t make sense to you rather than assuming we are somehow deviating from some norm.
Thanks,
Harbs
On Dec 5, 2014, at 10:19 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Could you please show us where this “standard release process” is documented, and explain how we are somehow deferring from this “standard”?
>
> The process is described here [1] which references [2] and best practise described here [3] and there is a work in progress with clearer MUSTs and SHOULDs in it. (I was unable to find the link)
>
> In short the normal process is to have one or more RCs each tagged in version control and placed on dist.apache.org along with a VOTE and a DISCUSS thread for each RC. The RM keeps making release candidates and putting them up for vote and discussion to the PMC until one gets the required 3 +1 binding votes (and more +1 than -1 votes). The RC is then moved to the release area and the release announced.
>
> Several bits of the noRC/lessRC (as described) deviate from this standard process, most of the deviations are minor (ie single discuss thread for all RCs), testing a nightly rather than the RC itself, but others are not ie the apparent need to build consensus before making a RC and calling for a vote. The later may be a misunderstanding of the then undocumented noRC process on my part, but that's what happened with the TourDeFlex release.
>
> With few PMC members voting a single -1 or indication that that how someone will vote can basically acts as a veto.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/release-publishing.html
> 2. http://www.apache.org/foundation/voting.html
> 3. http://incubator.apache.org/guides/releasemanagement.html
>
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Dec 5, 2014 at 10:07 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>> ...Does this PMC have trouble getting 4 people voting on a release?
> Yes, sometimes it hard to get 3 or 4 votes....
Ok, so that's something that this PMC should eventually fix - either
by electing more deserving PMC members, or convincing the current ones
to vote.
-Bertrand
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Does this PMC have trouble getting 4 people voting on a release?
Yes, sometimes it hard to get 3 or 4 votes.
> Either there's not enough active PMC members
That's certainly part of it.
Justin
RE: [TTH] vetoes get in the way
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
It does get to be quite a few emails some times. Send an email to [1] to remove yourself from this list. There is a better description here of the lists and their subscriptions [2].
[1] dev-unsubscribe@flex.apache.org
[2] http://flex.apache.org/community-mailinglists.html
-Mark
-----Original Message-----
From: Valdemar Lopes [mailto:valdemarlopes@gmail.com]
Sent: Friday, December 05, 2014 5:43 AM
To: dev@flex.apache.org
Subject: Re: [TTH] vetoes get in the way
Please remove me from this list.
2014-12-05 10:39 GMT+00:00 Harbs <ha...@gmail.com>:
> On Dec 5, 2014, at 11:18 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Being the release manager many time I can say that getting 3 or 4 vote
> is hard.
>
> The point of the “less RC” process it to try to make it easier on everyone
> to participate, so the hope is that this will improve over time. If getting
> votes is so hard, that might be an indication that something is wrong with
> how we’re doing things. I have not yet voted on a release. If it was really
> easy for me to check releases, I probably would have voted already.
>
> Harbs
Re: [TTH] vetoes get in the way
Posted by Valdemar Lopes <va...@gmail.com>.
Please remove me from this list.
2014-12-05 10:39 GMT+00:00 Harbs <ha...@gmail.com>:
> On Dec 5, 2014, at 11:18 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Being the release manager many time I can say that getting 3 or 4 vote
> is hard.
>
> The point of the “less RC” process it to try to make it easier on everyone
> to participate, so the hope is that this will improve over time. If getting
> votes is so hard, that might be an indication that something is wrong with
> how we’re doing things. I have not yet voted on a release. If it was really
> easy for me to check releases, I probably would have voted already.
>
> Harbs
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
On Dec 5, 2014, at 11:18 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Being the release manager many time I can say that getting 3 or 4 vote is hard.
The point of the “less RC” process it to try to make it easier on everyone to participate, so the hope is that this will improve over time. If getting votes is so hard, that might be an indication that something is wrong with how we’re doing things. I have not yet voted on a release. If it was really easy for me to check releases, I probably would have voted already.
Harbs
Re: [TTH] vetoes get in the way
Posted by Alex Harui <ah...@adobe.com>.
One of the reasons Justin may think we have trouble getting enough votes
is because of another interesting dynamic in Flex. When someone votes -1
on an RC because they found what they think is an important bug, folks
tend to stop testing and voting. I’ve actually tried not voting -1 and
simply asking for another RC in the DISCUSS thread, but I’m not sure that
helped either. The finding of an important issue just stops things in
their tracks.
What happens next is that voters wait for an RC with those issues fixed.
In just about every instance, as soon as a good quality RC is made
available we get enough votes. Because Justin often resists making
another RC, it probably appears to him that we have trouble getting enough
votes. I believe the only time it didn’t happen was this last release
when Justin didn’t want to carry over votes for the NOTICE and xml file
change.
Bertrand, do you know if other projects have this kind of problem and how
they deal with it? Also, I am under the impression that a +1 vote means
you have actually examined the package, which is why we added the notion
of carry-overs. A carry-over means that you didn’t examine the package
but trust by inference that nothing changed that would change your +1 vote
from a previous RC. Is there such a distinction or can we +1 by inference?
Thanks,
-Alex
On 12/5/14, 4:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>That's true for me. If it's got enough votes to pass, by people I trust,
>and I'm really busy, then I wont test it myself, or it I do it wont be
>formally enough to be worth a +1
>
>Tom
>
>On 05/12/14 12:14, Erik de Bruin wrote:
>> I think what we've seen is that all VOTEs get just enough votes to
>> pass because once enough passing votes are in, people choose to spend
>> the little time they have available for the projects on something
>> else.
>
Re: [TTH] vetoes get in the way
Posted by Tom Chiverton <tc...@extravision.com>.
That's true for me. If it's got enough votes to pass, by people I trust,
and I'm really busy, then I wont test it myself, or it I do it wont be
formally enough to be worth a +1
Tom
On 05/12/14 12:14, Erik de Bruin wrote:
> I think what we've seen is that all VOTEs get just enough votes to
> pass because once enough passing votes are in, people choose to spend
> the little time they have available for the projects on something
> else.
Re: [TTH] vetoes get in the way
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I think what we've seen is that all VOTEs get just enough votes to
pass because once enough passing votes are in, people choose to spend
the little time they have available for the projects on something
else.
3 votes are enough for a release, and I don't think we have to be
afraid of not reaching that target for any upcoming release.
EdB
On Fri, Dec 5, 2014 at 1:00 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Friday, December 5, 2014, Jeffry Houser <je...@dot-com-it.com> wrote:
>
>> ...Could part of the problem we have too many projects under the Apache
> Flex banner?
>> Do other Apache projects have 9+ completely separated, but related,
> projects?...
>
> The key is not how many modules you are managing but whether those belong
> to the same community.
>
> To take an example that I'm familiar with, Apache Sling manages more than
> 100 modules [1] and releases them very regularly. That works fine.
>
> Sometimes one needs to call for more PMC members to get enough votes on a
> module that interests only few people, and when that became hard we just
> went back to our list of committers and elected a bunch of them as PMC
> members (which also means you look for new committers often, as people also
> go). Because people care about the overall health of the project, they will
> take the time to vote on releases even for modules that they're not really
> interested in.
>
> -Bertrand
>
> [1] http://sling.apache.org/downloads.cgi
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
You can remove yourself from the list:
Subscribe: dev-subscribe@flex.apache.org
Post (after subscription): dev@flex.apache.org
Unsubscribe: dev-unsubscribe@flex.apache.org
Subscribe to digest: dev-digest-subscribe@flex.apache.org
Unsubscribe to digest: dev-digest-unsubscribe@flex.apache.org
On Dec 5, 2014, at 2:04 PM, Valdemar Lopes <va...@gmail.com> wrote:
> Please remove me from this list.
Re: [TTH] vetoes get in the way
Posted by Valdemar Lopes <va...@gmail.com>.
Please remove me from this list.
2014-12-05 12:00 GMT+00:00 Bertrand Delacretaz <bd...@apache.org>:
> On Friday, December 5, 2014, Jeffry Houser <je...@dot-com-it.com> wrote:
>
> > ...Could part of the problem we have too many projects under the Apache
> Flex banner?
> > Do other Apache projects have 9+ completely separated, but related,
> projects?...
>
> The key is not how many modules you are managing but whether those belong
> to the same community.
>
> To take an example that I'm familiar with, Apache Sling manages more than
> 100 modules [1] and releases them very regularly. That works fine.
>
> Sometimes one needs to call for more PMC members to get enough votes on a
> module that interests only few people, and when that became hard we just
> went back to our list of committers and elected a bunch of them as PMC
> members (which also means you look for new committers often, as people also
> go). Because people care about the overall health of the project, they will
> take the time to vote on releases even for modules that they're not really
> interested in.
>
> -Bertrand
>
> [1] http://sling.apache.org/downloads.cgi
>
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Friday, December 5, 2014, Jeffry Houser <je...@dot-com-it.com> wrote:
> ...Could part of the problem we have too many projects under the Apache
Flex banner?
> Do other Apache projects have 9+ completely separated, but related,
projects?...
The key is not how many modules you are managing but whether those belong
to the same community.
To take an example that I'm familiar with, Apache Sling manages more than
100 modules [1] and releases them very regularly. That works fine.
Sometimes one needs to call for more PMC members to get enough votes on a
module that interests only few people, and when that became hard we just
went back to our list of committers and elected a bunch of them as PMC
members (which also means you look for new committers often, as people also
go). Because people care about the overall health of the project, they will
take the time to vote on releases even for modules that they're not really
interested in.
-Bertrand
[1] http://sling.apache.org/downloads.cgi
Re: [TTH] vetoes get in the way
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 12/5/2014 4:18 AM, Justin Mclean wrote:
> most of the recent (last 6 months) Squiggly, Tour De Flex, FlexJS, Falcon releases have only have 3 or 4 votes each. (If you need links just ask).
Could part of the problem we have too many projects under the Apache
Flex banner?
Do other Apache projects have 9+ completely separated, but related,
projects?
The Flex SDK,
The SDK Installer,
Squiggly,
Tour De Flex,
FlexJS,
Falcon,
FlexUnit.
BlazeDS,
TLF
Am I missing anything?
The Apache Flex project feels like it became a dumping ground for
everything Flash / ActionScript related.
With so many different projects ongoing; it seems bound to split the
focus of everyone in the project. I can barely keep up and for the most
part stopped trying.
Am I wrong?
--
Jeffry Houser
Technical Entrepreneur
http://www.jeffryhouser.com
203-379-0773
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> In this particular instance, Justin decided to discard 2 votes instead of carrying them over
As I (not unreasonably IMO) thought that changes to a NOTICE file required PMC overview before making a release. But even with those 2 votes were counted there were only 4 votes. The final release was 3 votes.
Being the release manager many time I can say that getting 3 or 4 vote is hard. The last 4.13 SDK only just passed with +3 and a -1 (me btw), 4.12 (4 +1) and most of the recent (last 6 months) Squiggly, Tour De Flex, FlexJS, Falcon releases have only have 3 or 4 votes each. (If you need links just ask).
Thanks,
Justin
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
Agreed.
Re: [TTH] vetoes get in the way
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I think this discussion has gone on long enough. Time to stop trying
to convince each other, as that obviously is not going to happen.
Is there something here that can be resolved by a vote? If so, please
start a VOTE thread.
Otherwise let's end this discussion and move on.
Thanks,
EdB
On Fri, Dec 5, 2014 at 11:45 AM, Harbs <ha...@gmail.com> wrote:
> Again, you seem to have a different definition of “should”[1]. Nowhere does it state that if you do not mention it when you start the thread, the votes can not carry over.
>
> Of course it’s the RM’s choice. No one has stated that Om’s vote was valid if you refused to carry it over. You said you COULDN’T carry it over. That’s not true. You refused to carry it over. That’s a very different thing.
>
> [1]http://www.merriam-webster.com/dictionary/should
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
Again, you seem to have a different definition of “should”[1]. Nowhere does it state that if you do not mention it when you start the thread, the votes can not carry over.
Of course it’s the RM’s choice. No one has stated that Om’s vote was valid if you refused to carry it over. You said you COULDN’T carry it over. That’s not true. You refused to carry it over. That’s a very different thing.
[1]http://www.merriam-webster.com/dictionary/should
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> As per our guidelines the votes need to be carried other in the VOTE for the RC and I didn't do that.
>
> That’s simply not true.
Yes it is: [1]
"When voting on release candidates the release manager at their discretion can carry over votes from the previous release candidate if there are minimal changes between release candidates. This should be indicated in the new release candidate vote."
Either way it's the RM choice not the committers. If you want the guidelines to change please start a vote to change them.
Justin
1. https://cwiki.apache.org/confluence/display/FLEX/Guidelines
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
On Dec 5, 2014, at 11:28 AM, Justin Mclean <ju...@me.com> wrote:
> As per our guidelines the votes need to be carried other in the VOTE for the RC and I didn't do that.
That’s simply not true.
A vote can be carried over if the person who voted requested it should be carried over. It was stated by numerous PMC members that the vote could still be carried over. You refused to cooperate with the majority understanding of the policy.
Harbs
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@me.com>.
Hi,
> Om did ask his vote to be carried over, repeatedly and explicitly.
As per our guidelines the votes need to be carried other in the VOTE for the RC and I didn't do that. I would of had to cancel that RC and make another one in order to carry over votes. If it was a change to a read me or similar I probably wouldn't of been so strict, but changes to NOTICE files are sort of important. :-) There was nothing stopping PMC members who voted +1 to just vote again and it would of been less effort all round.
Justin
Re: [TTH] vetoes get in the way
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> Ok, I didn't study the details but I agree that you cannot carry over
> votes from one release candidate to the next, for example, without
> voters individually and explicitly indicating that you can do so. This
Om did ask his vote to be carried over, repeatedly and explicitly.
http://markmail.org/message/4eums5feczv2rg4a
http://markmail.org/message/g4agwngdjrfazdoy
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Dec 5, 2014 at 10:01 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> ...In this particular instance, Justin decided to discard 2 votes instead
> of carrying them over, which the majority of the participating PMC
> members were advocating...
Ok, I didn't study the details but I agree that you cannot carry over
votes from one release candidate to the next, for example, without
voters individually and explicitly indicating that you can do so. This
is one thing where you need to have a correct archive of who voted +1
on what.
Note that casting another +1 is actually less typing than saying "yes
you can carry my vote over" ;-)
-Bertrand
Re: [TTH] vetoes get in the way
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> If you guys have trouble getting 4 voters, something's wrong. Either
In this particular instance, Justin decided to discard 2 votes instead
of carrying them over, which the majority of the participating PMC
members were advocating. He put himself in the position he's now
complaining about.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Dec 5, 2014 at 9:19 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...The process is described here [1] which references [2] and
> best practise described here [3]...
Apart from not having vetoes on release votes, the only things that
the ASF requires about releases are captured in this excerpt from [1],
which defines several of the terms user later on the same page:
> An Apache release is a set of valid , signed , artifacts, voted on by
> the appropriate PMC and distributed on the ASF's official
> release infrastructure
[3] in particular is detailed recommendations for podlings during
incubation, I wouldn't put too much weight on it. PMCs are free to
handle the steps that allow them to fulfill the above requirements in
any way they see fit. The simpler the better IMO and it's also fine
for different release managers to work differently, from the ASF's
point of view.
> ...With few PMC members voting a single -1 or indication that that how
> someone will vote can basically acts as a veto....
Does this PMC have trouble getting 4 people voting on a release? If
you get 4 votes, a -1 is definitely not a veto as per
http://www.apache.org/foundation/glossary.html#MajorityApproval
If you guys have trouble getting 4 voters, something's wrong. Either
there's not enough active PMC members, or people think voting +1 on a
release means they agree to have their head cut off if a bug is found
in it later. That's not the case, by far. Voting +1 on a release means
you think publishing it is progress towards your goals, and to the
best of your knowledge you think it complies with the above
requirements.
-Bertrand
> 1. http://www.apache.org/dev/release-publishing.html
> 2. http://www.apache.org/foundation/voting.html
> 3. http://incubator.apache.org/guides/releasemanagement.html
>
Re: [TTH] vetoes get in the way
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Justin,
This shows you do not understand the 'less-RC' process. The major
difference between current and 'less-RC' is in the period leading up
to the creation of the first RC. The process once the first RC has
been posted and a vote has been started is the same and therefore
remains in accordance with Apache guidelines.
EdB
On Fri, Dec 5, 2014 at 9:19 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Could you please show us where this “standard release process” is documented, and explain how we are somehow deferring from this “standard”?
>
> The process is described here [1] which references [2] and best practise described here [3] and there is a work in progress with clearer MUSTs and SHOULDs in it. (I was unable to find the link)
>
> In short the normal process is to have one or more RCs each tagged in version control and placed on dist.apache.org along with a VOTE and a DISCUSS thread for each RC. The RM keeps making release candidates and putting them up for vote and discussion to the PMC until one gets the required 3 +1 binding votes (and more +1 than -1 votes). The RC is then moved to the release area and the release announced.
>
> Several bits of the noRC/lessRC (as described) deviate from this standard process, most of the deviations are minor (ie single discuss thread for all RCs), testing a nightly rather than the RC itself, but others are not ie the apparent need to build consensus before making a RC and calling for a vote. The later may be a misunderstanding of the then undocumented noRC process on my part, but that's what happened with the TourDeFlex release.
>
> With few PMC members voting a single -1 or indication that that how someone will vote can basically acts as a veto.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/release-publishing.html
> 2. http://www.apache.org/foundation/voting.html
> 3. http://incubator.apache.org/guides/releasemanagement.html
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Could you please show us where this “standard release process” is documented, and explain how we are somehow deferring from this “standard”?
The process is described here [1] which references [2] and best practise described here [3] and there is a work in progress with clearer MUSTs and SHOULDs in it. (I was unable to find the link)
In short the normal process is to have one or more RCs each tagged in version control and placed on dist.apache.org along with a VOTE and a DISCUSS thread for each RC. The RM keeps making release candidates and putting them up for vote and discussion to the PMC until one gets the required 3 +1 binding votes (and more +1 than -1 votes). The RC is then moved to the release area and the release announced.
Several bits of the noRC/lessRC (as described) deviate from this standard process, most of the deviations are minor (ie single discuss thread for all RCs), testing a nightly rather than the RC itself, but others are not ie the apparent need to build consensus before making a RC and calling for a vote. The later may be a misunderstanding of the then undocumented noRC process on my part, but that's what happened with the TourDeFlex release.
With few PMC members voting a single -1 or indication that that how someone will vote can basically acts as a veto.
Thanks,
Justin
1. http://www.apache.org/dev/release-publishing.html
2. http://www.apache.org/foundation/voting.html
3. http://incubator.apache.org/guides/releasemanagement.html
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
Justin,
Could you please show us where this “standard release process” is documented, and explain how we are somehow deferring from this “standard”?
Thanks,
Harbs
On Dec 5, 2014, at 9:12 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> That's why I recommend following the standard Apache rules and
>> recommendations. at [1] And also, as I said, because Flex is a
>> relatively small PMC that can save energy by just sticking to the ASF
>> standard things, without having to spend much time discussing its own
>> variants.
>
> I'm interested to know does that opinion (and as you say the PMC would be under no obligation to follow) include sticking to the standard release process and not trying to come up with our own variant?
>
> Thanks,
> Justin
Re: [TTH] vetoes get in the way
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> That's why I recommend following the standard Apache rules and
> recommendations. at [1] And also, as I said, because Flex is a
> relatively small PMC that can save energy by just sticking to the ASF
> standard things, without having to spend much time discussing its own
> variants.
I'm interested to know does that opinion (and as you say the PMC would be under no obligation to follow) include sticking to the standard release process and not trying to come up with our own variant?
Thanks,
Justin
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Dec 4, 2014 at 6:28 PM, Alex Harui <ah...@adobe.com> wrote:
> ...the reason our guidelines require consensus for adding
> people is because of this document [1] and some advice from other
> experienced non-Flex Apache people that having consensus for adding folks
> is important...
I agree if consensus means "widespread agreement" but in this PMC's
guidelines it seems to mean "unanimity". That meaning is definitely
against [1] where the first paragraph says "one of the fundamental
aspects of accomplishing things within the Apache framework is doing
so by consensus".
The word consensus at [1] clearly points to the "widespread agreement"
variant of http://en.wiktionary.org/wiki/consensus. So by redefining
that in your guidelines you have created a variant of the standard
Apache understanding of that word, which can be confusing to
outsiders, like myself when I subscribed back to this list a few days
ago.
Back to vetoes - as I said, my recommendation is to take -1s into
account *at the community level* when voting in new committers for
example. So in general if someone says -1 try to find out what's
behind that and act accordingly. And usually don't proceed - but
there's no obligation for the PMC.
So that's different from formally allowing such -1 to block committer
election or other votes, releases etc. That gives people the power to
block things even without justification, with potentially bad
consequences on the project's well-being. You want things to move
forward, even if this means putting some PMC members in a minority
sometimes. If that sometimes becomes "always" the community should
address that, but "sometimes" is ok for the sake of moving on. When
things get difficult, veto power is a very powerful weapon for people
who want to show their disagreement or just block things for political
reasons. Too powerful actually, so [1] avoids vetoes for most
occurences of consensus ("widespread agreement") building.
That's why I recommend following the standard Apache rules and
recommendations. at [1] And also, as I said, because Flex is a
relatively small PMC that can save energy by just sticking to the ASF
standard things, without having to spend much time discussing its own
variants.
But that's just my opinion, there's no obligation for you guys to
follow up on that. I just think it might avoid problems in the medium
and long term.
-Bertrand
[1] http://www.apache.org/foundation/voting.html
Re: [TTH] vetoes get in the way
Posted by Alex Harui <ah...@adobe.com>.
On 12/4/14, 5:47 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>On Thu, Dec 4, 2014 at 9:14 AM, Harbs <ha...@gmail.com> wrote:
>> ...If you feel it should be changed anyway, I have no objections to
>>that...
>
>I havent checked if allowing vetoes for many things has caused
>problems or not so far but I see a potential for creating blocking
>problems, so fixing that now is probably a good idea.
For some context, the reason our guidelines require consensus for adding
people is because of this document [1] and some advice from other
experienced non-Flex Apache people that having consensus for adding folks
is important. In fact, I assumed that [1] meant we didn’t have a choice
on voting rules for adding people. If you say that isn’t true, I’d be
happy to switch to majority vote.
-Alex
[1] https://community.apache.org/newcommitter.html
Re: [TTH] vetoes get in the way
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Dec 4, 2014 7:19 AM, "Bertrand Delacretaz" <bd...@apache.org>
wrote:
>
> On Thursday, December 4, 2014, OmPrakash Muppirala <bi...@gmail.com>
> wrote:
>
> > BTW, what does the TTH in the subject line strands for?
>
> Trying To Help - I made that up a few days ago,
> http://flex.markmail.org/thread/re2q3mxlzws76x26
Ah, I missed that somehow. Thanks!
Om
>
> -Bertrand
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thursday, December 4, 2014, OmPrakash Muppirala <bi...@gmail.com>
wrote:
> BTW, what does the TTH in the subject line strands for?
Trying To Help - I made that up a few days ago,
http://flex.markmail.org/thread/re2q3mxlzws76x26
-Bertrand
Re: [TTH] vetoes get in the way
Posted by OmPrakash Muppirala <bi...@gmail.com>.
BTW, what does the TTH in the subject line strands for?
Thanks,
Om
On Dec 4, 2014 7:14 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz" <bd...@apache.org>
> wrote:
> >
> > On Thu, Dec 4, 2014 at 9:14 AM, Harbs <ha...@gmail.com> wrote:
> > > ...If you feel it should be changed anyway, I have no objections to
> that...
> >
> > I havent checked if allowing vetoes for many things has caused
> > problems or not so far but I see a potential for creating blocking
> > problems, so fixing that now is probably a good idea.
>
> Allowing vetoes on committer voting had caused a lot of issues in the
> recent past. The private ML archive has all the details.
>
> I would like to see that one go, for sure.
>
> Thanks,
> Om
>
> >
> > -Bertrand
>
Re: [TTH] vetoes get in the way
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz" <bd...@apache.org>
wrote:
>
> On Thu, Dec 4, 2014 at 9:14 AM, Harbs <ha...@gmail.com> wrote:
> > ...If you feel it should be changed anyway, I have no objections to
that...
>
> I havent checked if allowing vetoes for many things has caused
> problems or not so far but I see a potential for creating blocking
> problems, so fixing that now is probably a good idea.
Allowing vetoes on committer voting had caused a lot of issues in the
recent past. The private ML archive has all the details.
I would like to see that one go, for sure.
Thanks,
Om
>
> -Bertrand
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 4, 2014 at 9:14 AM, Harbs <ha...@gmail.com> wrote:
> ...If you feel it should be changed anyway, I have no objections to that...
I havent checked if allowing vetoes for many things has caused
problems or not so far but I see a potential for creating blocking
problems, so fixing that now is probably a good idea.
-Bertrand
Re: [TTH] vetoes get in the way
Posted by Tom Chiverton <tc...@extravision.com>.
On 04/12/14 08:14, Harbs wrote:
>> I just readhttps://cwiki.apache.org/confluence/display/FLEX/Guidelines
>> >and I think allowing vetoes for most everything
> Really?
>
> I thought the only votes where vetoes are allowed are for voting in new committers/PMC members/PMC Chair.
Code change is 'lazy' which on our current definition allows a single
veto -1.
Tom
Re: [TTH] vetoes get in the way
Posted by Harbs <ha...@gmail.com>.
On Dec 4, 2014, at 10:05 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
> and I think allowing vetoes for most everything
Really?
I thought the only votes where vetoes are allowed are for voting in new committers/PMC members/PMC Chair.
Personally, I see no reason why those can’t be by majority vote, but I don’t think it’s caused issues either.
If you feel it should be changed anyway, I have no objections to that (as long as we don’t prolong the discussions on the topic) ;-)
Should we add a definition for “other topics” which would have a majority vote?
Harbs
Re: [TTH] vetoes get in the way
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 4, 2014 at 9:24 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> ...The only Consensus votes remaining in our guidelines (that I can find)
> are for the addition or removal of people in 'official' Apache
> positions (Committers and PMC members)....
FWIW I am even suggesting that you guys drop this "consensus" voting
definition and stick to what's defined at
http://www.apache.org/foundation/voting.html, as per my first email in
this thread.
If this was a 50-people PMC I might have a different recommendation,
but as things stand I think being as "standard" as possible will help.
-Bertrand
Re: [TTH] vetoes get in the way
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
> and I think allowing vetoes for most everything, as those guidelines
> do, is calling for trouble.
We recently voted to change the default vote type from Consensus to
Majority Approval.
The only Consensus votes remaining in our guidelines (that I can find)
are for the addition or removal of people in 'official' Apache
positions (Committers and PMC members). I can't recall the exact
arguments, but this was discussed at length by the PMC when we wrote
the guidelines and even revisited some time later.
I would certainly reconsider changing those votes to Majority Approval.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl