incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Podling releases and release policy
Date Wed, 05 Jun 2019 18:33:38 GMT
Given that [1] says "may" and not "will" and that Roy has said that if it isn't illegal and
better than the last release it is ok to ship a release candidate, maybe the ASF should adopt
the approach that every release policy issue that isn't about the legal right to distribute
some IP can be addressed in the next release if a TLP, and by graduation if a podling.

My 2 cents,

On 6/4/19, 8:00 PM, "Justin Mclean" <> wrote:

    Thanks Sam for the advice.
    > Been lurking.  Before I proceed, I will note that you have two members
    > of the board and one infrastructure representative participating.
    > Each has either explicitly or implicitly supported the idea of the
    > incubator setting direction for podlings.
    Set direction sure, but does that include ignoring board policy? While we do currently
for minor issues, I’m reasonably sure the board is OK with that, well none have complained.
I’m not sure if doing that for serious issues is overstepping the mark or not.
    See, for example, "why a foundation wide policy is needed”:  [1]
    "Deviations from this policy may have an adverse effect on the legal shield's effectiveness,
or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged
without prior, explicit board approval”
    > Now my observation.  My experience is that when a PMC comes to the
    > board with an open ended question asking for advice, the responses are
    > not crisp.
    Understood. I was asked by a board member to ask the question in the next report, although
they may not of been wearing that hat at the time.
    > An approach I have found much more successful: come up with a
    > proposal.  Often times it will get approved.  Some times you will be
    > asked to make changes. 
    OK I've written down what we currently do and that some have expressed an opinion that
podling should be able to ignore distribution policy up until graduation in the current report.
There is some support for it and no strong objection if that is OK by the board which is I
think close to consensus.
    If I am mistaken there please speak up.
    Personally I don’t really care either way other than A) if I vote on or am a release
manger for a release do I have the ASF legal protection (even if that release has serious
issues) and B) it’s clearer when podlings need to fix issues.
    I’m happy to change what I’ve written in the report into a proposal with the view
that, from now on that IPMC will allow serious issues in podling releases, so the board only
needs to say yes/no either explicitly or implicitly rather than choose from a list of options
a sit currently worded.
    If permission is given, then we’ll modify documentation and the DISCLAIMER to cover
this and you’ll see fewer -1 votes. Podlings will be expected (as before) to fix all issues
before graduation, so this may potentially block some podlings from graduation.
    If they say no then we'll refine the list of serious issues we vote -1 on and communicate
that to podlings. I think we can reasonably agree on that list with perhaps one possible exception
(compiled code in binaries).
    If anyone disagrees with this approach, or has an alternative suggestion, please speak
    To unsubscribe, e-mail:
    For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message