incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Ease of release process and exit criteria
Date Fri, 19 Aug 2016 20:41:00 GMT
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


Mime
View raw message