incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinayak Borkar <>
Subject Re: [DISCUSS] Release Apache VXQuery Incubating 0.2 (RC4)
Date Thu, 17 Oct 2013 05:46:40 GMT
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 

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.


On 10/16/13 7:13 PM, Marvin Humphrey wrote:
> Hi Vinayak,
> On Thu, Oct 10, 2013 at 3:40 PM, Vinayak Borkar <> 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
>      <>.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message