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 <m...@apache.org> 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 > enough). 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. http://www.apache.org/legal/release-policy.html#release-approval 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: https://wiki.apache.org/incubator/January2014 and > https://wiki.apache.org/incubator/IncubatorIssues2013 > <https://wiki.apache.org/incubator/IncubatorIssues2013> 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 decision/resolution) Yes, the decision how/whether to approve non-conforming releases is an Incubator PMC decision, not a board decision. Regards, Craig > > regards, > Mick > > Craig L Russell c...@apache.org
