WIP - Summary of Apache Release Policies
1. The incubation policy documentation [1] stipulates:
When a Podling decides it wants to make an ASF release, the Podling MUST hold a vote on their public dev list. At least three +1 votes are required (see the Apache Voting Process page) and more +1 votes than -1 votes. If the vote passes the Podling MUST send a summary of that vote to the Incubator’s general list and request that the Incubator PMC approve the release. Three +1 Incubator PMC votes are required to approve a release.
2. The Apache Release Management guide [2] mentions Podling Constraints, stating:
"In order for a podling to receive full permission from the IPMC to execute the release, the release vote must be held on the incubator general list and pass based on the standard Package Release voting rules. Only Incubator PMC votes are binding, but everyone is encouraged to vote.”
3. Justin posted a thread [3] which appears self-contradictory at times, but the bottom would imply that +3 binding on general@ is necessary...
[1] says that you need +3 votes and more +1 than -1 on dev, but doesn’t actually stipulate that the dev@ VOTE requires ANY binding votes. A second VOTE needs be held on general@. +3 binding VOTEs are required. Note that this doesn’t stipulate what approval looks like on general@ if you have +3 IPMC from dev@. Does +1 on general@ indicate approval, if you carry over +3 IPMC from dev@?
[2] says that the VOTE must be held on the incubator general@, under standard Package Release rules. In context, that would require that +3 IPMC (VOTES) and more +1 than -1 are required on general@.
[3] says a bunch of stuff, but strongly implies that 2 separate votes are required.
So, going forward is the most efficient policy to do lean votes on dev@, e.g., the second we hit +3 (+1 > -1) (binding or no), we push to general@ and then put in the elbow grease to drum up binding VOTEs there?
3 binding VOTE'd from Incubator Project Management Committee (IPMC) meembers
I’ve been watching general@ for some time and I’m aware of the heartburn with the dual voting issue...
Yes it can be an absolute PITA believe me I've been around long enough and seen so much frustration over this... especially in the past when IPMC could not get 3 VOTE'd together.
but policies seem vague about exactly what we need on general@ in the case we get +3 binding VOTEs on dev@.
The policy is the same for dev@ as it is for general@... 3 x +1 from binding *PMC members.
In the future should I just hold VOTES on general@ and cc dev@ ?
No. Always have it on dev@ first. The 2 step process is designed to not overwhelm general@ with unnecessary VOTE threads which only unearth things which should have been caught on dev@
Feel free to point to any documentation you think is relevant.
I've not watched it all the way through but Justin did a piece on this which is now linked to so I can only assume that it is well supported
https://www.youtube.com/watch?v=I0-lp1t9ee0
[1] https://incubator.apache.org/policy/incubation.html
[2] http://incubator.apache.org/guides/releasemanagement.html#best-practice
[3] see first email from Justin McLean on general@ thread titled, "[DISCUSS] IPMC votes on releases”. (sorry can’t find general@ on lists…)