Re: [DISCUSS] Release Apache VXQuery Incubating 0.2 (RC4)
Hi Marvin, It has now been close to a month since my email to which you replied. We were short by one vote then and we are short by one vote today. In the meantime there were issues raised regarding the distribution of ODC-BY content which was discussed on LEGAL-182 as you know and appears to have reached lazy consensus that it is OK for VXQuery to distribute the content about a week and a half ago. However, we are still short one vote and cannot release. At this time, I am not really sure what it is that the Incubator expects from the podling to make this release happen. It would be great if you have any ideas that could help us get this release out. 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Release Apache VXQuery Incubating 0.2 (RC4)
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
[DISCUSS] Release Apache VXQuery Incubating 0.2 (RC4)
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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Release Apache VXQuery Incubating 0.2 (RC4)
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. 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. 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,
