Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Subject: Re: Addition to the project maturity model
To: dev@community.apache.org
References: <10d3a222-0bd0-c232-69b1-fd678ca21df6@apache.org>
 <CACsi250DuWcJ+ozedSb7GKQhL0dw_cBWSxqJaQTesnt13n0mJQ@mail.gmail.com>
From: Phil Steitz <phil.steitz@gmail.com>
Message-ID: <f81553cd-d0ff-7bac-3f0a-ab23c6d17a4d@gmail.com>
Date: Sat, 1 Oct 2016 15:24:40 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CACsi250DuWcJ+ozedSb7GKQhL0dw_cBWSxqJaQTesnt13n0mJQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sat, 01 Oct 2016 22:24:59 -0000

On 9/29/16 6:25 AM, William A Rowe Jr wrote:
> On Wed, Sep 28, 2016 at 3:33 AM, Mark Thomas <markt@apache.org> wrote:
>
>> All,
>>
>> After a discussion on the general@incubator.a.o mailing list [1], I'd
>> like to propose the following addition to the project maturity model.
>>
>> RE50
>> The release process is documented and repeatable to the extent that
>> someone new to the project is able to independently generate a release=

>> build.
>>
> Release 'build'? That sounds very .jar'ish to me :)
>
> In non-JVM environments, we may have radically different ways of buildi=
ng,
> even on linux a project may have autoconf vs cmake as parallel options.=

> No single release manager is expected to try all alternatives across so=
me
> broad array of target platforms.
>
> The project must also demonstrate that they have documented how-to
> for users/consumers to generate a binary build from the release package=
=2E
> In terms of maturity, that might start out as windows-only or unix-only=

> or java-only, but as the project evolves more supported build platforms=
,
> they will have the template for adding more build how-to documentation.=

>
> Since binaries are not releases, is it enough to say 'release package'
> to capture the essence of tarball, .zip, or whatever the sources includ=
e?
> If a project wants to include the .jar file as a side effect of creatin=
g the
> release sources, I think 'release package' covers that to.

I agree with your points on limiting RM responsibility.  I draw the
line at the stock binaries that the PMC publishes directly.  I think
our policy [1] implies that binaries that are published by the PMC
are releases.  When PMCs push stock binaries to the ASF mirrors,
these binaries are in fact part of the release.  What I think we
need to capture as a maturity objective is that someone new to the
project can figure out how to build both source and binary
distributions (here, binary means what ends up VOTEd on and pushed
to the ASF mirrors [2]).  Building (and verifying at VOTE time [3])
binary distributions published by the project includes verifying
that anyone with the required build tools can reproduce them from
the source distribution.

I think that what Mark is trying to capture is just the idea that
there is not a ridiculously high bar or special access / tools
required for someone new to the project to step up to RM a release.=20
Packaging stock binaries is part of that.  The ability to recreate
the stock binaries from the source distribution is covered by
release policy.

Phil

[1] http://www.apache.org/dev/release.html#what
[2] There is a corner case for Java projects - "publishing" to maven
central - those artifacts are also IMO released by the PMC
[3] http://www.apache.org/dev/release.html#approving-a-release


>
> Otherwise, strongly +1 to this suggestion.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org