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. [1]
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[2].
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 [1] to reflect that a different process applies during
incubation.
- Sam Ruby
[1]
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
[2]
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
