You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2017/02/16 01:26:26 UTC
Approving flawed release candidates
Greets,
We take pains to advise downstream consumers that podling releases are
"incubating" because they may not live up to the standards expected of
Apache TLPs -- whether that is because the community is not mature,
because the release is not fully compliant with ASF policies, or what
have you.
A while back, the IPMC arrived at a consensus about the circumstances
under which we might approve incubating release candidates which are
legal to distribute yet do not fulfill all aspects of Apache policy.
A test was proposed by IPMC member and ASF Board member Bertrand
Delacretaz: "Does it put the Foundation at risk?"
https://wiki.apache.org/incubator/January2014
3. Consensus was built for a controlled regime for relaxing policy on
incubating releases under appropriate circumstances, potentially
reducing the number of release candidates we force podlings to
cycle through.
The first release candidate approved under that relaxed regime bundled
jar files in the source release. The podling promised to remove them in
the next point release (and subsequently followed through):
* Exercising the new regime for controlled relaxation of policy, a
bugfix release by Spark (0.8.1) which bundled jar files was approved
by the IPMC after the podling presented a roadmap to eliminating
them in the next minor point release (0.9).
For IPMC members evaluating a flawed release candidate (whether Mentors
or "freelance" IPMC reviewers on general@incubator), perhaps consider
the following workflow:
1. When policy violations which do not put the Foundation at risk
are discovered in an RC, vote -1 until tickets are filed. Once
they're filed, change vote to +1.
2. If a release candidate has policy issues which were brought to
light on a previous RC and should reasonably have been fixed
already, vote -1. (We may be tolerant but we're still serious.)
In particular, there are two common classes of problem that I think can
be handled this way:
The first is licensing documentation bugs, such as missing "forwarded"
dependency licenses in LICENSE, and extra junk in NOTICE. (Actual
licensing violations which make the RC illegal to redistribute are a
different story.)
The second is bundled compiled code, such as jar files. I've written at
length elsewhere on why we exclude these systemically (as have others
such as Roy Fielding), but they are a policy issue rather than a legal
issue.
Finally, there's one other common case worth mentioning which requires
slightly different treatement: dependencies with unapproved licenses.
These may be OK for incubating releases, but first require approval by
VP Legal.
Incubation disclaimers give us the flexibility to bring podlings into
compliance incrementally. At the same time, because podlings may not be
in compliance, incubation disclaimers are important -- two sides of the
same coin.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Approving flawed release candidates
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Feb 15, 2017 at 8:17 PM, Julian Hyde <jh...@gmail.com> wrote:
> While I agree with what both John and Marvin are saying, the key word here
> is “discretion”.
+1 for IPMC members applying discretion. I've submitted some suggestions
which I hope other IPMC members will consider, and I've tried to think them
though carefully, but situations will inevitably arise where the suggested
workflow is an awkward fit. For instance, a judgment call is required when
there's a dispute as to whether an issue was fixed, as John discusses
elsethread.
> Obviously the IPMC shouldn’t give podlings too hard a time
> (we all know how difficult and time consuming it is to go through a cycle
> consisting of a release candidate and TWO votes, and the mechanics of the
> release process are intimidating to the uninitiated). But also IPMC members
> are at liberty to say “I don’t like the look of that, I’m voting -1”. A -1
> doesn’t veto a release (we just need 3 more +1s than -1s), and IPMC members
> can always change their vote after a discussion.
It seems we're basically on the same page. However, there have been multiple
instances going back a ways where the IPMC had the option to let through a
flawed but legal RC, yet the podling was asked to respin. This thread isn't
just in response to the recent Traffic Control vote.
I'm not sure it's been clear to all our IPMC members when the option to
approve a release with policy flaws is available, so I thought it was
worthwhile to review the rationale and to analyze some of the most common
cases.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Approving flawed release candidates
Posted by Julian Hyde <jh...@gmail.com>.
While I agree with what both John and Marvin are saying, the key word here is “discretion”. Obviously the IPMC shouldn’t give podlings too hard a time (we all know how difficult and time consuming it is to go through a cycle consisting of a release candidate and TWO votes, and the mechanics of the release process are intimidating to the uninitiated). But also IPMC members are at liberty to say “I don’t like the look of that, I’m voting -1”. A -1 doesn’t veto a release (we just need 3 more +1s than -1s), and IPMC members can always change their vote after a discussion.
I would strongly recommend podlings to log JIRA cases when issues raised during the vote. If they show that they are committed to fixing those issues in the next release, the IPMC almost always relents. Conversely, nothing pisses me off more when reviewing a release than seeing the same issue I raised last release, and you can guess how I’m going to vote when I feel my time has been wasted.
Julian
> On Feb 15, 2017, at 6:54 PM, John D. Ament <jo...@apache.org> wrote:
>
> Hi Marvin,
>
> I don't think there's anything you're stating here that isn't in accordance
> to processes we have been following. If I look at the current Traffic
> Control vote, the problems I see are:
>
> - Assertion from the podling that they fixed the release, and votes from
> mentors indicating they fixed the prior release problems, but in actuality
> many of them are not fixed.
>
> - In the prior release vote (and I apologize, I missed that there was an
> RC8 passed our way), questions were raised by Justin asking for JIRA
> tickets for the open issues that were not addressed, without any response
> (hence I can only assume no JIRAs were filed)
>
> In general, I think what you're describing is what we're following. Its
> the uncommon case where an imperfect release is being revoted on, mostly
> because of the podling not following up with questions.
>
> I'll point out that the Singa vote is one where I feel the current legal
> advice is vague enough that I cannot make a clear statement whether or not
> allowing the release would put any legal strain on the ASF, in addition to
> it being vague enough on what we consider a build tool, or how to interpret
> the autoconf headers. One way to look at it - the ASF would produce GPL'd
> code which is a big no-no (and I wouldn't think would be acceptable as a
> JIRA ticket to fix later).
>
> - John
>
>
> On Wed, Feb 15, 2017 at 8:27 PM Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
>> Greets,
>>
>> We take pains to advise downstream consumers that podling releases are
>> "incubating" because they may not live up to the standards expected of
>> Apache TLPs -- whether that is because the community is not mature,
>> because the release is not fully compliant with ASF policies, or what
>> have you.
>>
>> A while back, the IPMC arrived at a consensus about the circumstances
>> under which we might approve incubating release candidates which are
>> legal to distribute yet do not fulfill all aspects of Apache policy.
>> A test was proposed by IPMC member and ASF Board member Bertrand
>> Delacretaz: "Does it put the Foundation at risk?"
>>
>> https://wiki.apache.org/incubator/January2014
>>
>> 3. Consensus was built for a controlled regime for relaxing policy on
>> incubating releases under appropriate circumstances, potentially
>> reducing the number of release candidates we force podlings to
>> cycle through.
>>
>> The first release candidate approved under that relaxed regime bundled
>> jar files in the source release. The podling promised to remove them in
>> the next point release (and subsequently followed through):
>>
>> * Exercising the new regime for controlled relaxation of policy, a
>> bugfix release by Spark (0.8.1) which bundled jar files was approved
>> by the IPMC after the podling presented a roadmap to eliminating
>> them in the next minor point release (0.9).
>>
>> For IPMC members evaluating a flawed release candidate (whether Mentors
>> or "freelance" IPMC reviewers on general@incubator), perhaps consider
>> the following workflow:
>>
>> 1. When policy violations which do not put the Foundation at risk
>> are discovered in an RC, vote -1 until tickets are filed. Once
>> they're filed, change vote to +1.
>> 2. If a release candidate has policy issues which were brought to
>> light on a previous RC and should reasonably have been fixed
>> already, vote -1. (We may be tolerant but we're still serious.)
>>
>> In particular, there are two common classes of problem that I think can
>> be handled this way:
>>
>> The first is licensing documentation bugs, such as missing "forwarded"
>> dependency licenses in LICENSE, and extra junk in NOTICE. (Actual
>> licensing violations which make the RC illegal to redistribute are a
>> different story.)
>>
>> The second is bundled compiled code, such as jar files. I've written at
>> length elsewhere on why we exclude these systemically (as have others
>> such as Roy Fielding), but they are a policy issue rather than a legal
>> issue.
>>
>> Finally, there's one other common case worth mentioning which requires
>> slightly different treatement: dependencies with unapproved licenses.
>> These may be OK for incubating releases, but first require approval by
>> VP Legal.
>>
>> Incubation disclaimers give us the flexibility to bring podlings into
>> compliance incrementally. At the same time, because podlings may not be
>> in compliance, incubation disclaimers are important -- two sides of the
>> same coin.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Approving flawed release candidates
Posted by "John D. Ament" <jo...@apache.org>.
Hi Marvin,
I don't think there's anything you're stating here that isn't in accordance
to processes we have been following. If I look at the current Traffic
Control vote, the problems I see are:
- Assertion from the podling that they fixed the release, and votes from
mentors indicating they fixed the prior release problems, but in actuality
many of them are not fixed.
- In the prior release vote (and I apologize, I missed that there was an
RC8 passed our way), questions were raised by Justin asking for JIRA
tickets for the open issues that were not addressed, without any response
(hence I can only assume no JIRAs were filed)
In general, I think what you're describing is what we're following. Its
the uncommon case where an imperfect release is being revoted on, mostly
because of the podling not following up with questions.
I'll point out that the Singa vote is one where I feel the current legal
advice is vague enough that I cannot make a clear statement whether or not
allowing the release would put any legal strain on the ASF, in addition to
it being vague enough on what we consider a build tool, or how to interpret
the autoconf headers. One way to look at it - the ASF would produce GPL'd
code which is a big no-no (and I wouldn't think would be acceptable as a
JIRA ticket to fix later).
- John
On Wed, Feb 15, 2017 at 8:27 PM Marvin Humphrey <ma...@rectangular.com>
wrote:
> Greets,
>
> We take pains to advise downstream consumers that podling releases are
> "incubating" because they may not live up to the standards expected of
> Apache TLPs -- whether that is because the community is not mature,
> because the release is not fully compliant with ASF policies, or what
> have you.
>
> A while back, the IPMC arrived at a consensus about the circumstances
> under which we might approve incubating release candidates which are
> legal to distribute yet do not fulfill all aspects of Apache policy.
> A test was proposed by IPMC member and ASF Board member Bertrand
> Delacretaz: "Does it put the Foundation at risk?"
>
> https://wiki.apache.org/incubator/January2014
>
> 3. Consensus was built for a controlled regime for relaxing policy on
> incubating releases under appropriate circumstances, potentially
> reducing the number of release candidates we force podlings to
> cycle through.
>
> The first release candidate approved under that relaxed regime bundled
> jar files in the source release. The podling promised to remove them in
> the next point release (and subsequently followed through):
>
> * Exercising the new regime for controlled relaxation of policy, a
> bugfix release by Spark (0.8.1) which bundled jar files was approved
> by the IPMC after the podling presented a roadmap to eliminating
> them in the next minor point release (0.9).
>
> For IPMC members evaluating a flawed release candidate (whether Mentors
> or "freelance" IPMC reviewers on general@incubator), perhaps consider
> the following workflow:
>
> 1. When policy violations which do not put the Foundation at risk
> are discovered in an RC, vote -1 until tickets are filed. Once
> they're filed, change vote to +1.
> 2. If a release candidate has policy issues which were brought to
> light on a previous RC and should reasonably have been fixed
> already, vote -1. (We may be tolerant but we're still serious.)
>
> In particular, there are two common classes of problem that I think can
> be handled this way:
>
> The first is licensing documentation bugs, such as missing "forwarded"
> dependency licenses in LICENSE, and extra junk in NOTICE. (Actual
> licensing violations which make the RC illegal to redistribute are a
> different story.)
>
> The second is bundled compiled code, such as jar files. I've written at
> length elsewhere on why we exclude these systemically (as have others
> such as Roy Fielding), but they are a policy issue rather than a legal
> issue.
>
> Finally, there's one other common case worth mentioning which requires
> slightly different treatement: dependencies with unapproved licenses.
> These may be OK for incubating releases, but first require approval by
> VP Legal.
>
> Incubation disclaimers give us the flexibility to bring podlings into
> compliance incrementally. At the same time, because podlings may not be
> in compliance, incubation disclaimers are important -- two sides of the
> same coin.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>