On 17 October 2013 06:46, Vinayak Borkar <vinay...@gmail.com> wrote: > Hi Marvin, > > > Thanks for your email. I was unaware that votes are allowed to take a long > time. My understanding (albeit flawed, I guess) was that votes are allowed > to be outstanding for only 72 hours. Hence my email. >
My understanding is that votes *by convention* must be open for at least 72h in order to ensure that people across time zones and weekends get a reasonable chance to contribute to the vote. If the vote receives its quorum by the time the 72h period is closed, then the vote result can be called. If the vote has failed to reach that vote's quorum within the 72h period, then at the discretion of the person running the vote they can EITHER leave the vote open and start pinging people who have a vote that would count towards quorum to try and encourage them to cast OR throw in the towel and declare the vote void (which is another way of trying to get the attention of the people who can vote but haven't) Additionally, if the *entire* electorate (or for certain classes of vote > 50% of the entire electorate) votes before the 72h period is closed then the vote result can be called early. For example, if you have a vote where the result will be decided by more +1's than -1's and there are no vetos... if there are 10 people with a vote and 6 of them vote +1 within 10 minutes of calling the vote... there is no need to wait the full 72h (it would be polite to do so though) If you have a vote where the result is 3x+1 with no veto allowed (e.g. a release vote) you should not cut that short, as the -1's may indicate problems with the release that the release manager (i.e. the person running the vote) may want to address... though it is normally the discretion of the release manager as to whether they will go ahead with the release if they have 3x+1 and some -1's as technically they can release once they have 3x+1 (where those +1's are the binding ones of people who's vote contributes to the quorum) but smart release managers will pay attention to those "-1 (binding)" votes and see if there is merit in the objection. The key things to pay attention to, with any vote, are: * the electorate requirements - i.e. who has a binding vote... * the quorum requirements - i.e. how much of the electorate must cast a vote for the vote to be valid * the result requirements - i.e. what votes are required in order to call a vote result * the minimum duration - i.e. what is the minimum time required before either a result can be called or the vote abandoned By convention at the ASF, 72h is the default minimum duration. Shortening the duration may have no effect as you could be stalled waiting for quorum anyway, but there could be valid reasons (i.e. zero-day security issue) where a shorter release vote has merit. [repeatedly calling short votes because 5 of the electorate are in the same room and will all vote +1 within 30s of the vote being called will raise alarm bells all the way up to the board very quickly ;-)] The type of vote determines the quorum requirements but the reasonable convention is that votes need at least 3 votes from the electorate (i.e. the governing PMC... which for projects in the incubator is the IPMC). And for releasing source code form the ASF, the result requirement is at least 3x+1 from the electorate (no majority needed!!! though again release managers would be strongly advised to pay attention to any -1's be they from the electorate or not) -Stephen > I do agree that retirement is a valid part of a software system's > lifecycle. However, in the case of VXQuery the committers have quite some > juice left in them to make more progress at this time. In fact a lot more > work gets done on the project than what appears on "visible" forums like > mailing lists. We use IM and Skype much more than we use mailing lists. > > The whole release process has been pretty frustrating due to a combination > of two orthogonal factors that have just been a drain on the team. > > 1. While there are guidelines that need to be adhered to by a release, we > were struggling for a long time to automate the release process so that it > produced all the artifacts that were needed to satisfy Apache's > requirements. Instead of all the guidelines as the primary pointer to how > releases should be made, having one link to the parent pom that can be > inherited by a Maven-driven Java project that does all the heavy lifting of > creating a release that meets Apache guildelines would have got us to a > release a year ago. We finally found this POM by looking at the Helix > project that had made a successful release. > > 2. It feels that the whole voting process around releases is very ad-hoc > and not very efficient. In fact at times it appears very subjective. As an > example, look at the voting process around the RCs for VXQuery. All the > issues raised around RC_i (i > 1) have been true of the first RC created. > So clearly all the issues could have been raised at one go with RC1 and we > could have been done with this whole process months ago. If the Incubator > is serious about projects creating releases and going through the > "process", I think it is only fair to the projects that the IPMC tightens > the review process so that things get done more efficiently. I would like > to see some accountability with the IPMC regarding the review process when > it comes to voting down an RC when the same issue was true of a previous RC > and could have been pointed out before. > You can have such "screw tighteners" weigh in even on TLPs... where they fight you on each release trying to incrementally get you to where they want you to go by a kind of war of attrition. Personally I dislike that approach. I much rather somebody puts up all their issues *one time* and lets those in charge of the project address those that should be addressed and dismiss those that should be dismissed... on the other hand, you don't always see issues the first time you look... so it is not always deliberate "screw tightening"... I do think that some people could pay a bit more attention to their behaviour on votes to ensure that they stop screw-tightening (whether that is by accident or by design)... at least for votes towards any specific release (i.e. if on an RC series, state your issues one time and then only state if the issues are fixed / not fixed... you can address your other issues for the next release) > > Thanks for the ODC-BY comment. I do hope that issue is resolved quickly so > we can create a successful release. > > > Thanks, > Vinayak > > > On 10/16/13 7:13 PM, Marvin Humphrey wrote: > >> Hi Vinayak, >> >> On Thu, Oct 10, 2013 at 3:40 PM, Vinayak Borkar <vinay...@gmail.com> >> wrote: >> >> It has been over 72 hours since the vote for the first VXQuery release >>> has >>> been open, and we still do not have the one vote we need from an IPMC >>> member. I am unsure how this process works. >>> >> >> For the last four months, I've been tracking the elapsed time between >> when a >> release candidate is published on a podling dev list and the arrival of >> the >> third IPMC +1 vote. These stats are going into the Incubator's monthly >> report to the Board. The average is roughly a week. >> >> However, it's not unusual for some release votes to take longer. One of >> the >> risk factors associated with long VOTE times is incubating for a long >> time (as >> VXQuery has), because Mentors tend to drift away and leave a podling with >> insufficient active IPMC representation[1]. >> >> Some VOTEs are outliers, though. ODF Toolkit's last release waited 20 >> days; >> the recent VOTE for Allura's first incubating release stayed open for >> several >> weeks awaiting IPMC approval before the release candidate was finally >> withdrawn. (We've yet to see a new one.) >> >> A number of us have been trying to address the structural flaws in the >> Incubator for several years now, but it is challenging to strike a balance >> between granting podlings more autonomy and exercising our oversight >> responsibilities -- so most proposals do not achieve consensus. >> Personally, I >> now try to spend my cycles approaching the problem from another angle, by >> working on ways to lower the cost of reviewing releases. >> >> Until a few weeks ago, we heard from quite a few vocal IPMC members about >>> how the project did not deserve to remain in incubation >>> >> >> We don't want podlings to "remain in incubation" indefinitely -- we want >> them >> to either graduate, or retire. Please take my followup of the VXQuery >> July >> report in that context -- and please understand that there's nothing wrong >> with retiring, since all software has a life cycle and sometimes it's >> better >> for the individual members of the community to move on to other interests. >> Nevertheless, graduation is of course the desired outcome every time a >> podling >> enters incubation and it is great to see VXQuery's increased activity. >> >> because it was >>> unable to make a release. >>> >> >> Apache projects release. Communities which don't release don't belong >> here. >> >> Should VXQuery graduate and become a TLP, you will be expected to keep >> making >> releases according to Apache guidelines -- and demonstrating that the >> community is capable of making such releases is a crucial test. >> >> Now there is an attempt at a release that has been voted in by the PPMC, >>> but >>> there is complete radio silence on the vote. >>> >> >> Be persistent and polite and eventually you will break through. >> >> If you are unlucky enough to duplicate Allura's experience, you can at >> least >> rest assured that the Board is going to hear about it. >> >> I appeal to the same people who expressed their opinions a few weeks ago >>> to >>> at least look at the release we have created and vote either for or >>> against >>> it. >>> >> >> I rarely perform freelance release reviews any more because the current >> system >> infuriates me and I do not wish to spend my volunteer time perpetuating >> it. >> However, I'm pleased that the opportunity arose to contribute via the >> ODC-BY >> licencing question. >> >> Good luck, >> >> Marvin Humphrey >> >> [1] For more thoughts on the subject of Mentor attrition, see >> >> <http://markmail.org/message/**4tqu7xddpoxdsuuz<http://markmail.org/message/4tqu7xddpoxdsuuz> >> >. >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> general-unsubscribe@incubator.**apache.org<general-unsubscr...@incubator.apache.org> >> For additional commands, e-mail: >> general-help@incubator.apache.**org<general-h...@incubator.apache.org> >> >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > general-unsubscribe@incubator.**apache.org<general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: > general-help@incubator.apache.**org<general-h...@incubator.apache.org> > >
