I wonder if the requirement might be better phrased along the lines of "must have releases completed by a total of > 2 release managers".
Asking people if their documentation is correct and complete almost always results in a yes answer and a moral onus on the questioner to either accept that answer or go to the trouble of verifying if it is true. The reliability of this as a cross check is not worth having a requirement. Asking for names of people who have built the release, or better yet, run the process is much harder to sandbag. The word "sandbag" here should be pronounced to rhyme with "optimism" and isn't usually an intentional sort of deception. On Tue, Aug 23, 2016 at 12:56 PM, Julian Hyde <jh...@apache.org> wrote: > +1 Especially for point 2, adding to the maturity model. > > Finding a release manager can be a problem, but is also an opportunity: a > committer who wants to become more involved with project governance can > volunteer to be RM. A well-functioning project makes this process as smooth > as possible. > > Julian > > > On Aug 20, 2016, at 12:59 PM, Mark Thomas <ma...@apache.org> wrote: > > > > All, > > > > It seems there is general consensus that this is a good idea. I'm > > therefore going to do the following. > > > > 1. Draft some text to add to > > http://incubator.apache.org/guides/graduation.html#releases > > and bring that back to this list for discussion > > > > 2. Start a thread on dev@community about adding an item to the project > > maturity model. > > > > 3. Identify somewhere to put all the good suggestions for, and links to > > examples of, smooth release processes and then pull all the links > > and suggestions from this thread to that place. I have a vague > > recollection of seeing such a thing previously. I'll need to do some > > digging to see it I can find it. Any hints? > > > > Mark > > > > > > On 19/08/2016 21:41, Dave Fisher wrote: > >> I know of a podling like that where the release manager gave me push > back until I told him I could not vote +1 without build instructions I > could at least follow on my own local. > >> > >> That was some years ago. The podling graduated. The instructions were > not updated. The RM left. Now there is a bind. > >> > >> A requirement is a good idea, but it is no guarantee that the > instructions remain up to date. > >> > >> Suggestions: > >> > >> Is this info for the maturity model? > >> Should there be special and higher standards to make binary releases > "official"? > >> > >> Regards, > >> Dave > >> > >> Sent from my iPhone > >> > >>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton < > dennis.hamil...@acm.org> wrote: > >>> > >>> +1 to this, including the posts from Mark and Bertrand. > >>> > >>> I know of a project where this would have made a serious difference > for graduation and subsequent sustainability. > >>> > >>> - Dennis > >>> > >>>> -----Original Message----- > >>>> From: Shane Curcuru [mailto:a...@shanecurcuru.org] > >>>> Sent: Friday, August 19, 2016 07:08 > >>>> To: general@incubator.apache.org > >>>> Subject: Re: Ease of release process and exit criteria > >>>> > >>>> Bertrand Delacretaz wrote on 8/19/16 5:57 AM: > >>>>> Hi Mark, > >>>>> > >>>>> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas <ma...@apache.org> > >>>> wrote: > >>>>>> ...I'm thinking of a graduation criteria long the lines of: > >>>>>> "Is the release process clearly documented to the point that someone > >>>> new > >>>>>> to the project could produce a release build?"... > >>>> > >>>> +1, this is a critical point to include. We continue to see projects > >>>> struggling with releases when early volunteers leave and no-one else > >>>> really understands releases. > >>>> > >>>> ...snip... > >>>>> How about also adding an RE50 item to > >>>>> https://community.apache.org/apache-way/apache-project-maturity- > >>>> model.html > >>>>> about a repeatable release process? That's a discussion for > >>>>> community.a.o but what's your opinion? > >>>> > >>>> +1, this is both important to include philosophically as well as > >>>> practically. I.e. it's an important reminder that project technical > >>>> procedures need to be understandable by the *whole* community, not > just > >>>> the first few developers who created the project. > >>>> > >>>> - Shane > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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 > >>> > >> > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
