incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hen <>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Sun, 09 Jun 2019 07:34:07 GMT
Copying the proposal in so I have something to respond to :)

> Proposal
> That the IPMC can allow releases with serious issues in them to be
released and distributed without IPMC or legal VP approval. When this

I agree with other respondents that 'serious' seems bad here. To me the
serious ones are the only ones they can't release with.

ReleaseBlocking:  Has a LICENSE.  Legally permitted to release and complies
with the license via some mechanism.
GraduationBlocking:  Everything else; including complying with the license
via our preferred mechanism (i.e. we might want the MIT license text in our
LICENSE file, but would accept it being in the source header of the files

I don't see a need to go to the board on this :)

> podling will documents the issue as one blocking graduation and carry on
incubating. They will not be allowed to graduate until all serious release

+1 to documenting it as BlocksGraduation :)  Noting the 'serious' here

> issues have been fixed. The IPMC will add additional information to the
incubator DISCLAIMER to cover that podling release may not abide by all

The IPMC? That sounds like a people scaling problem. The podling committee
should handle it.

> terms of the ALv2 and may contain code under an incompatible license.

Incompatible is such a vague word. It's also very specific to one type of
GraduationBlocking issue. I would stick to:

"This release still has the following issues that will need to be resolved
before the Foo Project can graduate to an Apache vetted Top Level Project"
(or some such; I really want to say Apache-Certified Community, but that's
a different argument.

> All releases and podling web sites will be updated to include this where
> required.

This is a given.

> Notes
> The IPMC will come up with a well-defined list of those serious issues
and distribute to mentors, IPMC members and podlings so that everyone's
> expectations are clear. This proposal does not change the need for an
IPMC vote on podling releases.

Redefining "serious issues" to mean ones that block a release; they should
be writeable on the back of a couple of business cards. Taking serious
issues as ones that are not actually serious and only graduation blockers;
then +1. It should still be short, but a piece of paper seems good :)

> Can the board also confirm that the ASF's legal shield would cover people
making releases under this proposal?

Are the board lawyers? :) Until you have a well-defined list, I doubt
anything could be confirmed. I'd go with:  "Conceptually what you describe
could lead to a situation where a PPMC releases a project fully compliant
with the ASF's expectations. "


On Thu, Jun 6, 2019 at 11:45 PM Justin Mclean <>

> Hi,
> As suggested I’ve collated information from several threads and turned it
> into a proposal for the board. Any edits, feedback, agreement, disagreement
> etc etc is welcome. In particular it would be nice  to hear some feedback
> from people who are in favour of this.
> Note that this is important as it probably changes the advice mentors will
> give their podlings on releases and change in a positive way how we vote on
> releases with serious issues in them. If you are a mentor or vote on
> releases please read it. Again feedback welcome.
> If the board agrees with the proposal I think we'll need to update the
> incubator DISCLAIMER. I’ve suggested what we might add in the proposal but
> the exact changes can to be discussed here. If the board disagrees with the
> proposal I suggest we discuss and come up with a list of serious issues
> that the IPMC recommends voting -1 vote on a release. This is just
> guidance, not rules, and there may of course be exceptions. (For instance
> you could ask VP legal for an exception as has been done in the past.)
> That way mentors and podlings have clear expectations on releases must
> contain.
> The proposal can be found in the draft board report. [1]
> Thanks,
> Justin
> 1.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message