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,
-Alex
On 6/4/19, 8:00 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
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.
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23why&data=02%7C01%7Caharui%40adobe.com%7Cbc987bf1219d42bfa17e08d6e961fdd1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953004417339794&sdata=6yunnE%2BTZmQrD1mYiDpmgMRblswB4D1FX3NIYIrvX%2Fk%3D&reserved=0
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
