I'd rather not sanctify exceptions with a precise list, but rather stop at:
"During incubation, a podling's release package may not be perfect. It
will be up to mentors and IPMC members
to define the appropriate leeway".
Or something to that extent.
Thanks,
Roman.
On Mon, Dec 26, 2016 at 6:03 PM, John D. Ament <johndam...@apache.org> wrote:
> On Mon, Dec 26, 2016 at 12:36 PM Marvin Humphrey <mar...@rectangular.com>
> wrote:
>
>> On Mon, Dec 26, 2016 at 7:29 AM, John D. Ament <johndam...@apache.org>
>> wrote:
>>
>> > This policy as far as I can tell has never been used by any podling.
>>
>> It has been used once (by ODF Toolkit).
>>
>> > I believe the problem it was trying to solve was getting binding votes on
>> > releases which has mostly been fixed (release votes would go on for 20+
>> days
>> > back then).
>>
>> The initiative which culminated in the 2013 Alternate Voting Process had
>> some
>> secondary effects which turned out to be more important than the primary
>> effect.
>>
>> Most crucially, the IPMC achieved a common understanding about when to
>> approve
>> flawed release candidates that were legally OK yet not in compliance with
>> Apache policy. ("Does it put the Foundation at risk?" If not, then bias
>> towards approval.) Between that and the eventual success of a separate
>> initiative to codify and clarify official release policy, two important
>> ends
>> were achieved:
>>
>> * Arguments over release candidates ended sooner and became less
>> embittered.
>> * Podlings no longer had to cycle through so many release candidates,
>> reducing burnout for Mentors and allowing us to use the limited IPMC
>> release reviewing capacity more effectively.
>>
>
> So, would it perhaps make sense to include a blurb about what is expected
> of a release and what the goals of incubation should be? Something like:
>
> During incubation, a podling's release package may not be perfect. These
> errors may include:
> - Improper NOTICE/LICENSE files
> - Failures building from source
> - Inclusion of binaries in the source release
> - Source release not staged properly.
> - etc... (Justin any notes here?)
>
> These issues vary in severity, and may be pointed out as blocking or not
> blocking the release by the IPMC. Any blocking issues should cause the
> release to rerolled to fix the issue. Non-blocking issues should be
> entered into your issue tracker and planned to be fixed for the next
> release.
>
> John
>
>
>
>>
>> The problem of insufficient Mentor participation in release review has not
>> gone away, and we remain heavily dependent on Justin (most often) to
>> provide
>> both review and the additional vote. If Justin's involvement drops, the
>> Incubator is likely to have problems again.
>>
>> However, to address the remaining systemic flaws it seems wise to channel
>> our energies into policy and documentation streamlining, since that has
>> yielded better results.
>>
>> > So I was wondering, is this a policy we want to keep around?
>>
>> +1 to revert.
>>
>> The language was deliberately crafted as an addendum which would be easy to
>> back out. Ditching it will have no problematic consequences.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> 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
