Re: [TTH] vetoes get in the way
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" 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
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
You can remove yourself from the list: Subscribe: dev-subscr...@flex.apache.org Post (after subscription): dev@flex.apache.org Unsubscribe: dev-unsubscr...@flex.apache.org Subscribe to digest: dev-digest-subscr...@flex.apache.org Unsubscribe to digest: dev-digest-unsubscr...@flex.apache.org On Dec 5, 2014, at 2:04 PM, Valdemar Lopes wrote: > Please remove me from this list.
Re: [TTH] vetoes get in the way
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 wrote: > On Friday, December 5, 2014, Jeffry Houser 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
Please remove me from this list. 2014-12-05 12:00 GMT+00:00 Bertrand Delacretaz : > On Friday, December 5, 2014, Jeffry Houser 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
On Friday, December 5, 2014, Jeffry Houser 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
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
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-unsubscr...@flex.apache.org [2] http://flex.apache.org/community-mailinglists.html -Mark -Original Message- From: Valdemar Lopes [mailto:valdemarlo...@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 : > On Dec 5, 2014, at 11:18 AM, Justin Mclean > 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
Agreed.
Re: [TTH] vetoes get in the way
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 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
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
Please remove me from this list. 2014-12-05 10:39 GMT+00:00 Harbs : > On Dec 5, 2014, at 11:18 AM, Justin Mclean > 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
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
On Dec 5, 2014, at 11:18 AM, Justin Mclean 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
On Dec 5, 2014, at 11:28 AM, Justin Mclean 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
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
> 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
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
On Fri, Dec 5, 2014 at 10:07 AM, Justin Mclean 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
On Fri, Dec 5, 2014 at 10:01 AM, Erik de Bruin 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
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
> 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
Hi, On Fri, Dec 5, 2014 at 9:19 AM, Justin Mclean 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
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 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
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 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
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
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 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
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
Hi, On Thu, Dec 4, 2014 at 6:28 PM, Alex Harui 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
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
On 12/4/14, 5:47 AM, "Bertrand Delacretaz" wrote: >On Thu, Dec 4, 2014 at 9:14 AM, Harbs 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
On Dec 4, 2014 7:19 AM, "Bertrand Delacretaz" wrote: > > On Thursday, December 4, 2014, OmPrakash Muppirala > 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
On Thursday, December 4, 2014, OmPrakash Muppirala 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
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 wrote: > On Thu, Dec 4, 2014 at 9:14 AM, Harbs 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
BTW, what does the TTH in the subject line strands for? Thanks, Om On Dec 4, 2014 7:14 AM, "OmPrakash Muppirala" wrote: > > On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz" > wrote: > > > > On Thu, Dec 4, 2014 at 9:14 AM, Harbs 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
On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz" wrote: > > On Thu, Dec 4, 2014 at 9:14 AM, Harbs 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
On Thu, Dec 4, 2014 at 9:14 AM, Harbs 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
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
On Dec 4, 2014, at 10:05 AM, Bertrand Delacretaz 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
On Thu, Dec 4, 2014 at 10:48 AM, Tom Chiverton 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
On Thu, Dec 4, 2014 at 9:24 AM, Erik de Bruin 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
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
> 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
[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