incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Ease of release process and exit criteria
Date Sun, 21 Aug 2016 06:16:39 GMT
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 <aharui@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" <markt@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.hamilton@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:asf@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 <markt@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-unsubscribe@incubator.apache.org
> >>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> >
> >---------------------------------------------------------------------
> >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