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
