incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: Podling releases and release policy
Date Wed, 05 Jun 2019 03:00:18 GMT
Hi,

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 up.

Thanks,
Justin

1.  http://www.apache.org/legal/release-policy.html#why


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message