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, 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
