incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Thu, 13 Jun 2019 07:47:30 GMT
Maybe the next question is: Are all release policy violations showstoppers?  I suspect the
answer is no.  And thus, if any TLP can punt release policy violations to a future release,
then so can podlings, and the IPMC can let more things go without really needing another decision
from the board.  Or maybe the only question for board or some authority is:  Can the IPMC
be authorized to allow CatX in podling releases?

Ted gave an example in this thread of a legal issue where an attribution required by a dependency's
license is missing.  I believe I've seen some long-timers say that those are not showstoppers.
 Nobody is going to sue the ASF over that legal mistake as long as we respond positively towards
fixing it in the next release.

I also think Ted explained in this thread the "why" behind many release policies more clearly
and in fewer words than I recall from incubator documentation when I was in the incubator
in 2012.  And that might better educate podlings and TLPs on how to make good choices on what
can be deferred to a future release.

Seems like the only showstoppers for TLPs are:
1) content we have no right to distribute
2) content that distribution would break a law (maybe export restrictions, adult content)
3) CatX content

Maybe other legal issues like missing attributions MUST be fixed in the next release.

Other release policy violations SHOULD be fixed in the next release.

Not sure where to put inclusion of CatB source.  Would that also be a showstopper?

Podlings would be given flexibility on CatX/CatB, but also have showstoppers for
B) missing "-incubating" in the source artifact package name.

My 2 cents,

On 6/12/19, 11:44 PM, "Hen" <> wrote:

    On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean <>
    > Hi,
    > > I agree with other respondents that 'serious' seems bad here. To me the
    > > serious ones are the only ones they can't release with.
    > So we just continue as is then? You have any suggests to what we change?
    I don't think we're using the same word meanings.
    I think that serious = release blocker; but I equally think there are very
    few items that are serious.
    > > ReleaseBlocking:  Has a LICENSE.  Legally permitted to release and
    > complies
    > > with the license via some mechanism.
    > We currently allow releases that are not strictly legal. This would be a
    > step backwards.
    I'd love to hear some examples. I suspect they are all legal.
    Speculating hypothetically:
    * We should never make a release that we know there is some content in that
    we explicitly do not have permission to publish.
    * We should never make a release that we know contains content that is
    criminal (for whatever that would mean).
    Other than that... I'm not sure what else would come under 'all legal'
    > > 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
    > > themselves).
    > We currently allow podlings to graduate with some issues as longs as the
    > PPMC is dealing with them. This would be a step backwards.
    Yeah. We need a third category for "MehNotBlockingPleaseFix".
    > > I don't see a need to go to the board on this :)
    > If we don’t want to change anything - sure there's no need to go to the
    > board.
    I'd definitely like to see change. My feeling is that there's a lot we can
    make that falls comfortably within the scope of the Incubator PMC. IIRC the
    release policies came out of the Incubator; I don't recall there being a
    request for the board to ratify them, but I might be failing to remember
    something a decade+ ago :)
    > >> 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.
    > I mean just changing this page [1] , podlings can update their own
    > disclaimers.
    Gotya :)
    > > "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”
    > What about unknown issues?
    By that are you suggesting that the text implies a guarantee that those are
    the only issues? (Otherwise I'm off into philosophy of whether the unknown
    can exist when the only test makes it known :) ).
    "The Foo Project have currently identified the following issues that will
    need to be resolved before the project can graduate to an Apache vetted Top
    Level Project”
    Any better?
    > > 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. “
    > I assume you mean “not fully compliant”?
    I was being defensive in my broad statements. For the given question; sure,
    someone might manage a perfect release someday :)

View raw message