incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <>
Subject Incubator release votes
Date Tue, 26 Feb 2019 02:15:56 GMT
Hi Mick,

I appreciate your taking time to document what you have experienced in the incubator.

Apologies if these comments cross other discussions. It's hard to keep track of all the threads
that have forked from the original discussion.

> On Feb 24, 2019, at 4:35 PM, Mick Semb Wever <> wrote:
>> The mentors to the Apache Zipkin podling wish to raise an issue from 
>> their podling experience that we know negatively impacts more than just 
>> that one podling. This is being sent to the board@ because past 
>> podlings may have input, as well as this being a question of ASF 
>> culture at large.
> Thanks heaps everyone for taking this seriously. It's really appreciated. Apologies for
raising it first with the board, I understand people's frustrations that I did it so. I do
believe it better resulted in a broader discussion, with focus on the correct social aspects.

> There's a number of things that's been said, or referenced, that are incredibly helpful
for me to rely back with, both to the private@incubator and the podling. I'll list them here
(often paraphrasing) just to check I've got it straight.
> 0) It is an existing problem. Some consider the Incubator to have been broken for some
time now. The structure of the Incubator has lead to many of these issues, for example too
many cooks in the kitchen. And the problem is certainly amplified with large, productive podlings
that have existing well-running release trains, especially over many codebase repositories.

To me, the biggest issue with incubating releases has been lack of engagement by mentors for
release voting. Many examples from history have podlings begging for someone, anyone, to review
a release that has already received review in the podling dev list but has failed to attract
three +1 votes from Incubator PMC members.

This is really sad, because in most of these cases the mentors have not voted. And so it fell
to the rest of the IPMC members to pay attention enough to take time to vote.

And recently, three cheers for Justin who has become very active in looking at podling releases
and voting. More below.
> 1) The Incubator's mission should be as a "facilitator". That is being a service provider
for podlings to enter the Apache community, rather than a stern gatekeeper. The Incubator's
website especially needs an update to better illustrate this spirit and goal.

Patches welcome. Seriously though, there is very much material and a very small bit that may
seem to be contradictory. I'd suggest that when you stumble across a confusing part, document
it in an email and have a discussion.
> 2) The ASF is not just a "household seal of approval", podlings must expect to learn
and work to get the ASF processes and releases correct before they can graduate. A number
of fully compliant releases are expected before graduation. There is a lot to learn, and unfortunately
it's not well documented enough (or the documentation is not collected and presented well

Part of this is that although the rules for a PMC release are well documented and not well
understood even by long term members (SAD!) the reasons for an IPMC vote are personal.
> 3) We need to relax IPMC's input on release voting… 
>  -- Letting the first release be dealt with only by the PPMC and mentors. 

Putting a release on Apache infrastructure has legal implications. In order to protect individuals
from legal issues, Apache requires a release vote by the PMC (in this case, the IPMC) that
passes with a minimum of three +1 votes and more +1 votes than -1 votes.

So when someone votes -1, that vote does not block the release. So if all three mentors vote
+1, it takes three -1 votes before any additional voting is needed.

>  -- Understanding a minimal criteria every podling release must meet, and the broader
criteria that TLP releases need to meet. And podlings only need to demonstrate in releases
closer to graduation.

There are no minimal criteria. Most IPMC members have their own criteria and consider the
maturity of the podling before deciding to vote -1. 

The reason the podling releases come with a DISCLAIMER (emphasis mine) is that perfection
is not expected from podling releases. But it is expected that before graduating, podlings
are able to make releases that are fully compliant with Apache guidelines for releases.

Personally, having jar files in a first podling release is fine with me. +1. But I'd probably
vote -1 if that same issue were in the second podling release. And I'd not vote to exit the
incubator if there were not a fully conforming release done.

>  -- Getting the IPMC to work with ASF release checklist and filing jira tickets instead
of voting "-1" against the releases. Jira tickets better imply that the violation needs to
be addressed in some subsequent release before the podling graduation. This is a past resolution
by the Incubator back in January 2014: and
Yes, the board has explicitly told the Incubator that podling releases do not have to conform
in all respects to release guidelines.
> Does the above form an accurate summary of what's been said so far? (ie it's not a board

Yes, the decision how/whether to approve non-conforming releases is an Incubator PMC decision,
not a board decision.


> regards,
> Mick

Craig L Russell

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message