incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Date Wed, 14 Aug 2019 18:20:02 GMT
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.


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

    On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean <> 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
    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:
View raw message