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 

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.


On 8/14/19, 8:50 AM, "Sam Ruby" <> wrote:

    On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean <> 
    > Hi,
    > >> This is because of ASF bylaws i.e only PMC votes are binding on 
    > >
    > > 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
    If something like this were adopted by the IPMC, I will offer to help
    update [1] to reflect that a different process applies during
    - Sam Ruby
    To unsubscribe, e-mail:
    For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to