incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: [DISCUSS] Replacing Incubator Release Management guide
Date Fri, 30 Dec 2016 02:52:36 GMT
On Thu, Dec 29, 2016 at 6:40 PM, John D. Ament <johndament@apache.org> wrote:
> On Thu, Dec 29, 2016 at 9:31 PM Roman Shaposhnik <roman@shaposhnik.org>
> wrote:
>
>> On Thu, Dec 29, 2016 at 6:17 PM, John D. Ament <johndament@apache.org>
>> wrote:
>> > This is what I'm trying to say with these sentences:
>> >
>> > Those reviewing the releases will provide the release managers
>> >                     with information about what is wrong with the
>> release.
>> > Release managers should consider issues reported as blocking, unless told
>> > otherwise
>> >                     by those reporting the issue.
>> >
>> > I'd rather not use the term "pass" and I'd prefer if it were understood
>> by
>> > podlings that the default should be to try to fix the release, unless its
>> > explicitly called out.
>>
>> I understand, but the structure of the sentence makes it difficult to
>> appreciate
>> that mentors/IPMC folks are gatekeepers on what may and may not pass in
>> the incubating release. It is also somewhat confusing on the role of the
>> RM.
>>
>> So how about something like:
>>
>> It is well understood that one of the goals of incubation is to help a
>> podling understand how to build
>> ASF compliant releases. This is why its mandatory to have at least 3
>> +1 votes from IPMC members
>> review the releases (this may or may not include your mentors) for
>> accuracy in compliance with the
>> ASF and Incubator policies. The podling community, of course, needs to
>> be fully engaged in review
>> process as well. Anybody reviewing  the releases will provide the
>> release manager and IPMC members
>> with information about what is wrong  with the release. The severity
>> of the issues and whether they are
>> blocking or not is up to the discussion  but the ultimate guidance on
>> where podling releases may get
>> additional flexibility belongs to the mentors and IPMC members.
>>
>
> Ok, fair enough.  Hence why I always ask for people to give me their takes
> :-)
>
> I rephrased a couple of areas of what you wrote, what do you think?
>
> It is well understood that one of the goals of incubation is to help a
> podling understand how to
> build <a href="http://www.apache.org/dev/#releases">ASF compliant
> releases</a>. This is why its
> mandatory to have at least 3 +1 votes from
> <a
> href="&root-path;/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">IPMC
> members</a>
> review the releases (this should include your <a
> href="&root-path;/incubation/Roles_and_Responsibilities.html#Mentor">mentors</a>
> but is not mandatory)
> for accuracy in compliance with the ASF and <a
> href="&root-path;/incubation/Incubation_Policy.html#Releases">Incubator
> policies</a>.
> The podling community, of course, needs to be fully engaged in review
> process as well. Anybody reviewing
> the releases will provide the release manager and IPMC members with
> information about what is wrong
> with the release. The severity of the issues and whether they are blocking
> or not may be discussed
> but the ultimate guidance on where podling releases may get additional
> flexibility belongs to the mentors and IPMC members.
>
> One of the key things this draws to now is that we want to encourage
> mentors to review podling releases.

+1

Thanks,
Roman.

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


Mime
View raw message