You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Mark Thomas <ma...@apache.org> on 2016/09/28 08:33:36 UTC
Addition to the project maturity model
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.
If there are no objections, I'll add this some time next week.
Mark
[1]
https://lists.apache.org/thread.html/cf6a2ea3b969dc0e81ce49650f4418ab2480492c612bd2cacdf070dc@%3Cgeneral.incubator.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Niclas Hedhman <ni...@hedhman.org>.
That is an interesting one. And funny enough, there are two parts of that
IMHO.
1. Check out from source control repository, and re-produce a source
release build, resulting in a releasable artifact.
2. That the built artifact can be downloaded, and built for a given
platform/deployment.
In my project, we actually have the CI do the second step, verifying that
the release source artifact can be built on its own from tar file. I have
not seen that very often...
Cheers
Niclas
On Wed, Sep 28, 2016 at 4:33 PM, Mark Thomas <ma...@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.
>
>
> If there are no objections, I'll add this some time next week.
>
> Mark
>
> [1]
> https://lists.apache.org/thread.html/cf6a2ea3b969dc0e81ce49650f4418
> ab2480492c612bd2cacdf070dc@%3Cgeneral.incubator.apache.org%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Addition to the project maturity model
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 28 September 2016 at 19:26, Joan Touzet <jo...@lrtw.org> wrote:
> Big +1 here. Projects that can't be repeatably built risk decay
> faster than those that can.
+1 - as long as it is documented it doesn't matter if it says "copy
the file three times while jumping high in the air".
Obviously automated build/release simplifies things - documentation
would also highlight any special build infrastructure.
Not sure how a project can prove the "someone new to the project" bit
- perhaps this can be motivation to encourage new committers to (try
to) do a release?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Joan Touzet <jo...@lrtw.org>.
Big +1 here. Projects that can't be repeatably built risk decay
faster than those that can.
Given the needs of some build chains (especially Windows, in my
experience) I also endorse the fact that this does not specifically
call out /automated/ builds, though projects should be striving to
achieve those as much as possible anyway.
-Joan
----- Original Message -----
> From: "Mark Thomas" <ma...@apache.org>
> To: dev@community.apache.org
> Sent: Wednesday, September 28, 2016 4:33:36 AM
> Subject: Addition to the project maturity model
>
> 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.
>
>
> If there are no objections, I'll add this some time next week.
>
> Mark
>
> [1]
> https://lists.apache.org/thread.html/cf6a2ea3b969dc0e81ce49650f4418ab2480492c612bd2cacdf070dc@%3Cgeneral.incubator.apache.org%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Phil Steitz <ph...@gmail.com>.
On 9/29/16 6:25 AM, William A Rowe Jr wrote:
> On Wed, Sep 28, 2016 at 3:33 AM, Mark Thomas <ma...@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 building,
> even on linux a project may have autoconf vs cmake as parallel options.
> No single release manager is expected to try all alternatives across some
> 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.
> 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 include?
> If a project wants to include the .jar file as a side effect of creating 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.
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
Re: Addition to the project maturity model
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Sep 29, 2016 at 3:44 PM, Stian Soiland-Reyes <st...@apache.org> wrote:
> ...I'm not sure what is the deal with the BASIC line numbering idea of
> RE* - ....
Hehe, that idea came from someone who has actually been doing BASIC in
the past...on a Sharp calculator that was passed around during boring
classes in engineering school, to collaboratively program a game ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Stian Soiland-Reyes <st...@apache.org>.
"release artifacts"? Or does that hint to much of Maven?
We can do it as two different requirements..
RE50 - independendly generate a source archive (RE10).
RE60 - independently generate any convenience binaries (RE40)
I'm not sure what is the deal with the BASIC line numbering idea of
RE* - perhaps these additions could also be RE11 and RE41 to better
align.
On 29 September 2016 at 14:25, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Sep 28, 2016 at 3:33 AM, Mark Thomas <ma...@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 building,
> even on linux a project may have autoconf vs cmake as parallel options.
> No single release manager is expected to try all alternatives across some
> 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.
> 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 include?
> If a project wants to include the .jar file as a side effect of creating the
> release sources, I think 'release package' covers that to.
>
> Otherwise, strongly +1 to this suggestion.
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Sep 28, 2016 at 3:33 AM, Mark Thomas <ma...@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 building,
even on linux a project may have autoconf vs cmake as parallel options.
No single release manager is expected to try all alternatives across some
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.
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 include?
If a project wants to include the .jar file as a side effect of creating the
release sources, I think 'release package' covers that to.
Otherwise, strongly +1 to this suggestion.
Re: Addition to the project maturity model
Posted by Mark Thomas <ma...@apache.org>.
On 04/10/2016 09:11, Bertrand Delacretaz wrote:
> On Tue, Oct 4, 2016 at 9:50 AM, Mark Thomas <ma...@apache.org> wrote:
>> ...I'm wondering about expanding "... generate a release." to "... generate
>> the complete set of artifacts required for a release."....
>
> Works for me, it's more precise.
Done.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Oct 4, 2016 at 9:50 AM, Mark Thomas <ma...@apache.org> wrote:
> ...I'm wondering about expanding "... generate a release." to "... generate
> the complete set of artifacts required for a release."....
Works for me, it's more precise.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Mark Thomas <ma...@apache.org>.
On 04/10/2016 08:22, Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, Sep 28, 2016 at 10:33 AM, Mark Thomas <ma...@apache.org> wrote:
>> ....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...
>
> I like it, would just remove the last "build" based on the comments
> made in this thread, so
>
> RE50
> The release process is documented and repeatable to the extent that
> someone new
> to the project is able to independently generate a release.
>
> I think "generating a release" adapts nicely to the different cases
> and fits the high-level view of the Maturity Model.
No objections to dropping "build".
I'm wondering about expanding "... generate a release." to "... generate
the complete set of artifacts required for a release.".
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Addition to the project maturity model
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Sep 28, 2016 at 10:33 AM, Mark Thomas <ma...@apache.org> wrote:
> ....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...
I like it, would just remove the last "build" based on the comments
made in this thread, so
RE50
The release process is documented and repeatable to the extent that
someone new
to the project is able to independently generate a release.
I think "generating a release" adapts nicely to the different cases
and fits the high-level view of the Maturity Model.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org