On Thu, Dec 29, 2016 at 9:31 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Thu, Dec 29, 2016 at 6:17 PM, John D. Ament <johndam...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
