incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: [DISCUSS] Replacing Incubator Release Management guide
Date Fri, 30 Dec 2016 02:40:47 GMT
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.

John


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message