IMO, the key change as already been made: There is now a WIP-disclaimer. AFAICT, the rest of this thread has been an attempt to create an objective process around a subjective topic (in this case risk). The better use of time may be to just launch an experiment by making the one change suggested by Greg: That Infra and the board will allow a podling to put packages containing the WIP-disclaimer on dist.a.o as long as those packages also include "-incubating" or "-incubator" in the package name.
IMO, if that can be agreed to by the stakeholders, those stakeholders are agreeing that any risks to the foundation and RMs posed by Justin are worth taking and we can hopefully just move on and find out what happens. Ideally, the WIP-disclaimer makes the IPMC vote: 1) optional 2) helpful 3) advisory ...instead of "potentially blocking". This new disclaimer should allow mentors to allow the podlings to publish packages for their users the way they probably did before entering incubation. The podlings will have the option to push the packages to dist.a.o and then, if they want the legal shield protection, call for a vote from the IPMC if they don't have 3 mentor votes. The key risk here is whether the WIP disclaimer will help ward off possible legal action by a user of the package. IOW, is it too risky that something really awful will be missed by the mentors and PPMC in these packages? I doubt it. There might be GPL or proprietary code that needs to be replaced eventually. But the new disclaimer helps and I just think folks aren't going to try to sue the ASF or a podling RM during this transition period. If a podling is lucky enough to have 3 mentors review the packages, then that should make those packages an official ASF release and thus protect the RM. If there aren't 3 mentors reviewing the packages, then the podling will have a reason to call for an IPMC vote to get the 3 votes. The new disclaimer should greatly reduce the chances of a -1 vote. Instead, issues found will be logged in the podling's bug tracker. If the 3 mentors are certain enough of their review of the packages, then the podling can go on its merry way towards graduation. Otherwise, the podling should call for additional IPMC reviews of their packages in order to avoid major surprises before graduation. They just don't need to do it prior to publishing their packages, which makes the IPMC review helpful and advisory instead of potentially blocking. Yeah, there is a risk that a published package will be so awful it needs to be pulled in spite of the new disclaimer, but IMO, there is always a chance we've missed something. Practically speaking, if Justin is one of the 3 mentors, the podiing is probably in good shape heading towards graduation, of not, it probably is a good idea to get Justin to review the packages at some point. IMO, it shouldn't take a special team of Greg/Ross/David to do this experiment. As long as podlings can publish before the vote/review, and the new disclaimer makes the chance of pulling something back almost zero, every podling can choose this new route and the IPMC vote will rarely if ever be a gate. It was this late gate which was stricter with the old disclaimer that was the problem for Zipkin. HTH, -Alex On 8/14/19, 8:50 AM, "Sam Ruby" <ru...@intertwingly.net> wrote: On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean <jus...@classsoftware.com> wrote: > > Hi, > > >> This is because of ASF bylaws i.e only PMC votes are binding on releases. > > > > That is not in the Bylaws. Stop making stuff up. > > That the way it’s been explained to me, several times, by experienced ASF people, that only PMC votes are binding on releases and podlings are not mentioned in the ASF bylaws. Bylaw wise see section 6.3. But you're right, it would be more precise to say, it's a combination of 6.3 of the bylaws of the ASF and the ASF's policy on voting on releases.  Concrete suggestion, and an offer to help. The ASF bylaws contain a lot of curiosities such as "each member of a Project Management Committee shall serve on such committee for a period of one year or until his or her successor is elected and qualified or until his or her earlier resignation or removal", and have been interpreted as the board is the one that determines membership of PMCs. Over time, that understanding has evolved, and is currently implemented as a notification requirement. Perhaps something similar can be made to work here. Outline of proposed process: 1) Concurrent with the start of a release vote by a PPMC, the IPMC is to be notified that that vote is happening. IPMC members are encouraged to participate in the vote process on the PPMC list where it is happening. 2) If anybody on the IPMC calls for a IPMC vote on the release before the release occurs, then the release is blocked from happening until this vote completes. 3) If the PPMC vote completes before there is a call for an IPMC vote, the PPMC is free to make the release. If such a process were in place, then the burden on the PPMC would be normally be reduced to a single email per release. Any IPMC member could still -- for any reason -- call for a full IPMC vote, but my sense is that that rarely will happen, and when it does, it will generally be because there is a substantive issue that needs to be resolved. If something like this were adopted by the IPMC, I will offer to help update  to reflect that a different process applies during incubation. - Sam Ruby  https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Fvoting.html%23ReleaseVotes&data=02%7C01%7Caharui%40adobe.com%7Ce6aeb72c7a74453596e008d720cf1bb5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637013946217354854&sdata=KNUMV3cXlX6jtTmRJ6qSIoM7YCWgPMGEeWeee1DWWpA%3D&reserved=0  https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhimsy.apache.org%2Fboard%2Fminutes%2FPMC_Membership_Change_Process.html&data=02%7C01%7Caharui%40adobe.com%7Ce6aeb72c7a74453596e008d720cf1bb5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637013946217354854&sdata=oPC65Uuo7FAPb181b5yr1W17X7NszX%2FLM4ojDhxyVho%3D&reserved=0 --------------------------------------------------------------------- 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