By "source package must be able to build itself", are you suggesting that simple projects must create scripts inside the source itself to execute a simple tar/zip command (for example), instead of just documenting those lines? That seems a bit frivolous to me.
On Sun, Aug 21, 2016 at 1:59 AM Alex Harui <aha...@adobe.com> wrote: > One more thought on this: Right now the 'requirement' is for PMC members > to be able to take the source package and build the binary before voting > +1. What if the 'requirement' became that the PMC members must be able to > take the source package and build both the binary and the source package? > IOW, a source package must be able to build itself. > > Thanks, > -Alex > > On 8/20/16, 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 > > > >
