You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Mark Thomas <ma...@apache.org> on 2016/08/19 09:23:43 UTC
Ease of release process and exit criteria
Hi,
I've noticed a pattern in some the board reports of PMCs who are
beginning to experience difficulties. In a notable number of cases a
significant part of the problem is difficulty in producing a release.
The sorts of phrases I am seeing are along the lines of releases "are
too difficult", "take too much effort" or "the person that used to do
the releases is no longer active". I've seen this in projects of all
sizes and maturity levels.
I've also experienced this in projects I have been involved in.
Fortunately, in those cases the community was able to figure out the
release process, simplify/automate it and document it, reducing the
future risk to the project.
To put some specifics on this to give an idea of what I am talking
about. The documented Windows build process for Tomcat Native is this:
http://tomcat.apache.org/native-doc/#Building/Windows
which is fine if you want to test a patch or build it form source to use
locally but is insufficient to produce a release. What the community
then produced is this:
https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows
This got me wondering. Is protecting projects from this sort of future
problem something that could / should be addressed during incubation?
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?"
If there is general consensus on this, I'm happy to draft something to
add to http://incubator.apache.org/guides/graduation.html#releases
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Craig Russell <cr...@oracle.com>.
In the JDO project, we have detailed build/release instructions, yet after several years, every time we put out a release, there is something different. I think it’s the nature of software, not only because the project changes ever so slightly but the dependencies also change underneath you. So having a release process is a good start but as many others have pointed out, not guaranteed.
Still, I think one exit criterion from incubation might well be: release instructions easy enough for even a Mentor to follow. I’m picking on mentors here (I am one), but they have all the karma needed but not necessarily the technical project skills. (That’s not what mentors are for).
Craig
> On Aug 19, 2016, at 1:55 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> As a data point, for Apache Geode we have a detailed release page:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Steps
>
> We’ve been rotating RM’s for each release and the notes get enhanced each time through the process.
>
> Feedback welcome!
>
> Thanks,
> Anthony
>
>
>> On Aug 19, 2016, at 7:33 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 8/19/16, 7:08 AM, "Shane Curcuru" <as...@shanecurcuru.org> wrote:
>>
>>> 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.
>>
>> So would graduation require that at least one IPMC member (not already in
>> the podling) can complete the release steps without getting an error?
>> Otherwise, there is a risk that folks point to a web page full of
>> instructions but nobody can actually get them to work.
>>
>> -Alex
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Anthony Baker <ab...@pivotal.io>.
As a data point, for Apache Geode we have a detailed release page:
https://cwiki.apache.org/confluence/display/GEODE/Release+Steps
We’ve been rotating RM’s for each release and the notes get enhanced each time through the process.
Feedback welcome!
Thanks,
Anthony
> On Aug 19, 2016, at 7:33 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 8/19/16, 7:08 AM, "Shane Curcuru" <as...@shanecurcuru.org> wrote:
>
>> 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.
>
> So would graduation require that at least one IPMC member (not already in
> the podling) can complete the release steps without getting an error?
> Otherwise, there is a risk that folks point to a web page full of
> instructions but nobody can actually get them to work.
>
> -Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Alex Harui <ah...@adobe.com>.
On 8/19/16, 7:08 AM, "Shane Curcuru" <as...@shanecurcuru.org> wrote:
>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.
So would graduation require that at least one IPMC member (not already in
the podling) can complete the release steps without getting an error?
Otherwise, there is a risk that folks point to a web page full of
instructions but nobody can actually get them to work.
-Alex
Re: Ease of release process and exit criteria
Posted by Alex Harui <ah...@adobe.com>.
On 8/20/16, 11:16 PM, "Christopher" <ct...@apache.org> wrote:
>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.
If by "simple projects" you mean those that simply package a tar/zip of a
repo, then I'm sure they could be an exception/degenerate-case/whatever.
But for any packaging that isn't simply a tar/zip of a repo, it might
force the scripting such that there isn't as much RM magic that can get
lost if key folks leave.
Just a thought,
-Alex
>
>On Sun, Aug 21, 2016 at 1:59 AM Alex Harui <ah...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Christopher <ct...@apache.org>.
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 <ah...@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
> >>><de...@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 <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-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
> >
>
>
Re: Ease of release process and exit criteria
Posted by Alex Harui <ah...@adobe.com>.
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
>>><de...@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 <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-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
>
Re: Ease of release process and exit criteria
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
+1
In practice this is often really a problem with many projects :/
LieGrue,
strub
> On Wednesday, 28 September 2016, 10:41, Mark Thomas <ma...@apache.org> wrote:
> > On 20/08/2016 20:59, Mark Thomas 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
>
> The text I propose adding to the end of the first sentence in "Creating
> an Apache Release" section is:
>
> It is also important for a project to document how to create a release.
> It should be possible for someone new to the project to work from the
> documentation to independently create a release. (Note: Creating a
> release is usually more complex than simply being able to build from
> source.)
>
> Thoughts?
>
>
> Mark
>
> ---------------------------------------------------------------------
> 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
Re: Ease of release process and exit criteria
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2016 20:59, Mark Thomas 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
The text I propose adding to the end of the first sentence in "Creating
an Apache Release" section is:
It is also important for a project to document how to create a release.
It should be possible for someone new to the project to work from the
documentation to independently create a release. (Note: Creating a
release is usually more complex than simply being able to build from
source.)
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2016 20:59, Mark Thomas wrote:
> 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?
I've added some content to:
http://incubator.staging.apache.org/guides/releasemanagement.html#best-practices-git-maven
http://incubator.staging.apache.org/guides/releasemanagement.html#best-practice-reproducability
Feel free to edit / enhance as necessary.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Stian Soiland-Reyes <st...@apache.org>.
Agreed, it is also a good way to "integration test" the documented release
process to have at least 2 release managers have a go.
If there are no emails on a podling list with questions on how to do a
release, then that hints of potential hidden knowledge, which as we see is
critical for future health of the project.
On 24 Aug 2016 4:19 a.m., "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
> On Tue, Aug 23, 2016 at 2:02 PM, Ted Dunning <te...@gmail.com>
> wrote:
> > I wonder if the requirement might be better phrased along the lines of
> > "must have releases completed by a total of > 2 release managers".
>
> I really like this criteria and use it extensively with my podlings.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Ease of release process and exit criteria
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Aug 23, 2016 at 2:02 PM, Ted Dunning <te...@gmail.com> wrote:
> I wonder if the requirement might be better phrased along the lines of
> "must have releases completed by a total of > 2 release managers".
I really like this criteria and use it extensively with my podlings.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Ted Dunning <te...@gmail.com>.
I wonder if the requirement might be better phrased along the lines of
"must have releases completed by a total of > 2 release managers".
Asking people if their documentation is correct and complete almost always
results in a yes answer and a moral onus on the questioner to either accept
that answer or go to the trouble of verifying if it is true. The
reliability of this as a cross check is not worth having a requirement.
Asking for names of people who have built the release, or better yet, run
the process is much harder to sandbag. The word "sandbag" here should be
pronounced to rhyme with "optimism" and isn't usually an intentional sort
of deception.
On Tue, Aug 23, 2016 at 12:56 PM, Julian Hyde <jh...@apache.org> wrote:
> +1 Especially for point 2, adding to the maturity model.
>
> Finding a release manager can be a problem, but is also an opportunity: a
> committer who wants to become more involved with project governance can
> volunteer to be RM. A well-functioning project makes this process as smooth
> as possible.
>
> Julian
>
> > On Aug 20, 2016, at 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.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 <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-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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Ease of release process and exit criteria
Posted by Julian Hyde <jh...@apache.org>.
+1 Especially for point 2, adding to the maturity model.
Finding a release manager can be a problem, but is also an opportunity: a committer who wants to become more involved with project governance can volunteer to be RM. A well-functioning project makes this process as smooth as possible.
Julian
> On Aug 20, 2016, at 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 <de...@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 <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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Mark Thomas <ma...@apache.org>.
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 <de...@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 <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-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
Re: Ease of release process and exit criteria
Posted by Dave Fisher <da...@comcast.net>.
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 <de...@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 <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-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
RE: Ease of release process and exit criteria
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+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 <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-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
Re: Ease of release process and exit criteria
Posted by Shane Curcuru <as...@shanecurcuru.org>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by "John D. Ament" <jo...@apache.org>.
In addition, the release steps here are also available on DS's website -
they've obviously been updated since the original, but are pretty close to
Mark's email: http://deltaspike.apache.org/steps_for_a_release.html
John
On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
>
> First and important: configure the maven-release-plugin to operate
> ‚locally‘
> https://github.com/apache/deltaspike/blob/master/pom.xml#L123
>
> The important parts are
> <pushChanges>false</pushChanges>
> <localCheckout>true</localCheckout>
>
> This will configure maven to NOT push you changes upstream to the repo
> mentioned in the SCM section, but only keep it local.
> And during the release:perform this will also pick up the tag from local.
> That means you need to push it to e.g. github yourself.
>
> Note that in most projects we do _not_ push the release candidate directly
> to the ASF repo but e.g. to the release managers private github account.
> Reason is that we cannot easily get rid of it from the cannonical ASF repo
> if the VOTE fails.
> (ASF repos get mirrored downstream in seconds, and while we could
> technically remove it from our own repo we have no control over all the
> clones).
>
> This is kind of symetrical to the maven repo staging aproach.
> And the sha1 is the same anyway if we merge the buid-branch to master and
> push it to the ASF repo later (when the VOTE did pass).
>
> Something very old I wrote up for DeltaSpike a few years ago where I
> described the steps:
>
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201309.mbox/%3C1378906506.82251.YahooMailNeo@web28902.mail.ir2.yahoo.com%3E
>
> hth.
>
> LieGrue,
> strub
>
>
> > Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz <
> bdelacretaz@apache.org>:
> >
> > 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?"...
> >
> > I like this - as another example we have
> >
> http://sling.apache.org/documentation/development/release-management.html
> > in Sling, and as someone who does releases in bursts that's very
> > useful.
> >
> >> ...If there is general consensus on this, I'm happy to draft something
> to
> >> add to http://incubator.apache.org/guides/graduation.html#releases ...
> >
> > +1 and it's good to add links such as the ones you mentioned and the
> > above if you think they are good examples.
> >
> > 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?
> >
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Ease of release process and exit criteria
Posted by "John D. Ament" <jo...@apache.org>.
I would personally love it if we came up with some best practices for new
projects as they're coming in. There's been a few very questionable ones
done in the past, not that they're bad or incorrect, but do become
burdensome. However, I've seen projects create amazing releases in short
periods of time. So then why don't those projects graduate already?
John
On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
>
> First and important: configure the maven-release-plugin to operate
> ‚locally‘
> https://github.com/apache/deltaspike/blob/master/pom.xml#L123
>
> The important parts are
> <pushChanges>false</pushChanges>
> <localCheckout>true</localCheckout>
>
> This will configure maven to NOT push you changes upstream to the repo
> mentioned in the SCM section, but only keep it local.
> And during the release:perform this will also pick up the tag from local.
> That means you need to push it to e.g. github yourself.
>
> Note that in most projects we do _not_ push the release candidate directly
> to the ASF repo but e.g. to the release managers private github account.
> Reason is that we cannot easily get rid of it from the cannonical ASF repo
> if the VOTE fails.
> (ASF repos get mirrored downstream in seconds, and while we could
> technically remove it from our own repo we have no control over all the
> clones).
>
> This is kind of symetrical to the maven repo staging aproach.
> And the sha1 is the same anyway if we merge the buid-branch to master and
> push it to the ASF repo later (when the VOTE did pass).
>
> Something very old I wrote up for DeltaSpike a few years ago where I
> described the steps:
>
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201309.mbox/%3C1378906506.82251.YahooMailNeo@web28902.mail.ir2.yahoo.com%3E
>
> hth.
>
> LieGrue,
> strub
>
>
> > Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz <
> bdelacretaz@apache.org>:
> >
> > 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?"...
> >
> > I like this - as another example we have
> >
> http://sling.apache.org/documentation/development/release-management.html
> > in Sling, and as someone who does releases in bursts that's very
> > useful.
> >
> >> ...If there is general consensus on this, I'm happy to draft something
> to
> >> add to http://incubator.apache.org/guides/graduation.html#releases ...
> >
> > +1 and it's good to add links such as the ones you mentioned and the
> > above if you think they are good examples.
> >
> > 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?
> >
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Ease of release process and exit criteria
Posted by Christopher <ct...@apache.org>.
On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
>
> First and important: configure the maven-release-plugin to operate
> ‚locally‘
> https://github.com/apache/deltaspike/blob/master/pom.xml#L123
>
> The important parts are
> <pushChanges>false</pushChanges>
> <localCheckout>true</localCheckout>
>
>
+1 This is super-critical for maven-release-plugin users. It'd be nice to
have these in the parent POM, but there is also a risk that the source code
which is actually used to create the release candidate is never pushed to
the repository. There's actually quite a few manual steps outside the
maven-release-plugin one must do in ASF to get things staged, uploaded, and
ready for a vote.
To solve this for Accumulo, I wrote a pretty comprehensive build script
that automates some of the manual steps we'd normally do with git during
and after the maven commands to stage the release candidate in Nexus:
https://s.apache.org/accumulo-build-script
Unfortunately, we've not done a good job of ensuring the documentation is
up-to-date to document this process manually. It's on my TODO list, though,
and I think it'd be great for incubating projects to ensure the steps
(whatever they are for their particular project) to create release
candidates is documented prior to graduation.
Re: Ease of release process and exit criteria
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Actually we have 3 different 'staging' mechanisms at play when using Apache Maven with GIT:
1.) the Maven staging at repository.apache.org
2.) the temp GIT repo
3.) the dist/dev.
The third is actually not used by all projects. The feature was not that prominently advertised and for maven projects you have the release binary candidates in the maven staging repo anyway.
Actually 3 is most times populated by curling from 1 ;)
But it's of course a great place to put release candidates if you are not using Maven (like AOO)!
LieGrue,
strub
> On Friday, 19 August 2016, 17:41, Dennis E. Hamilton <de...@acm.org> wrote:
> >
>
>> -----Original Message-----
>> From: Mark Struberg [mailto:struberg@yahoo.de.INVALID]
>> Sent: Friday, August 19, 2016 03:19
>> To: general@incubator.apache.org
>> Subject: Re: Ease of release process and exit criteria
>>
>> Good links.
>>
>> I’d like to add some information for projects who use GIT with maven:
> [ ... ]
>> Note that in most projects we do _not_ push the release candidate
>> directly to the ASF repo but e.g. to the release managers private github
>> account.
>> Reason is that we cannot easily get rid of it from the cannonical ASF
>> repo if the VOTE fails.
>> (ASF repos get mirrored downstream in seconds, and while we could
>> technically remove it from our own repo we have no control over all the
>> clones).
> [orcmid]
>
> The ASF SVN supports a staging process by which projects have a place to put
> dev-only builds that are for testing and consideration as release candidates.
> How that would tie into GIT-only projects and Maven as used is a different
> matter and distinguishing between non-released developer artifacts, release
> candidates, and releases seems to be much trickier.
>
> Using AOO as an example, the place where artifacts for dev-only use and handling
> as release candidates are at
>
> <https://dist.apache.org/repos/dist/dev/openoffice>. Release candidates
> on which deliberation fails to achieve release approval can be deleted from
> there.
>
> When a release candidate is identified and approved as a release, it is copied
> or moved to
>
> <https://dist.apache.org/repos/dist/release/openoffice> along with the
> signatures and hashes that were with the candidate in the dev area. (Using SVN,
> this is a cheap copy.)
>
> That is the staging point for a general, public distribution.
> Within something like 24-48 hours, the content of that release area is
> automatically mirrored to
>
> <https://archive.apache.org/dist/openoffice>
>
> And THAT is the official public availability point (with whatever mirroring and
> other downstream distribution there happens to be). That is where the indelible
> KEYS, hashes, signatures, etc. are to be accessed and the material is preserved
> in perpetuity.
>
> Deletions at dist.apache.org do not have any effect on the archive.apache.org
> artifacts, so one can clean-up by removing those. This is SVN so the artifacts
> are not completely gone, but they are not available for mistaken download by
> direct access to those locations.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Ease of release process and exit criteria
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Mark Struberg [mailto:struberg@yahoo.de.INVALID]
> Sent: Friday, August 19, 2016 03:19
> To: general@incubator.apache.org
> Subject: Re: Ease of release process and exit criteria
>
> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
[ ... ]
> Note that in most projects we do _not_ push the release candidate
> directly to the ASF repo but e.g. to the release managers private github
> account.
> Reason is that we cannot easily get rid of it from the cannonical ASF
> repo if the VOTE fails.
> (ASF repos get mirrored downstream in seconds, and while we could
> technically remove it from our own repo we have no control over all the
> clones).
[orcmid]
The ASF SVN supports a staging process by which projects have a place to put dev-only builds that are for testing and consideration as release candidates. How that would tie into GIT-only projects and Maven as used is a different matter and distinguishing between non-released developer artifacts, release candidates, and releases seems to be much trickier.
Using AOO as an example, the place where artifacts for dev-only use and handling as release candidates are at
<https://dist.apache.org/repos/dist/dev/openoffice>. Release candidates on which deliberation fails to achieve release approval can be deleted from there.
When a release candidate is identified and approved as a release, it is copied or moved to
<https://dist.apache.org/repos/dist/release/openoffice> along with the signatures and hashes that were with the candidate in the dev area. (Using SVN, this is a cheap copy.)
That is the staging point for a general, public distribution.
Within something like 24-48 hours, the content of that release area is automatically mirrored to
<https://archive.apache.org/dist/openoffice>
And THAT is the official public availability point (with whatever mirroring and other downstream distribution there happens to be). That is where the indelible KEYS, hashes, signatures, etc. are to be accessed and the material is preserved in perpetuity.
Deletions at dist.apache.org do not have any effect on the archive.apache.org artifacts, so one can clean-up by removing those. This is SVN so the artifacts are not completely gone, but they are not available for mistaken download by direct access to those locations.
>
> This is kind of symetrical to the maven repo staging aproach.
> And the sha1 is the same anyway if we merge the buid-branch to master
> and push it to the ASF repo later (when the VOTE did pass).
>
> Something very old I wrote up for DeltaSpike a few years ago where I
> described the steps:
> http://mail-archives.apache.org/mod_mbox/deltaspike-
> dev/201309.mbox/%3C1378906506.82251.YahooMailNeo@web28902.mail.ir2.yahoo
> .com%3E
>
> hth.
>
> LieGrue,
> strub
>
>
> > Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz
> <bd...@apache.org>:
> >
> > 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?"...
> >
> > I like this - as another example we have
> > http://sling.apache.org/documentation/development/release-
> management.html
> > in Sling, and as someone who does releases in bursts that's very
> > useful.
> >
> >> ...If there is general consensus on this, I'm happy to draft
> something to
> >> add to http://incubator.apache.org/guides/graduation.html#releases
> ...
> >
> > +1 and it's good to add links such as the ones you mentioned and the
> > above if you think they are good examples.
> >
> > 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?
> >
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > 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
Re: Ease of release process and exit criteria
Posted by Martijn Dashorst <ma...@gmail.com>.
For Wicket I've crafted a release script that not only creates the
artifacts to vote on, but also generates the messages needed for
voting and announcing, and scripts to either promote or rollback a
release.
https://github.com/apache/wicket/blob/master/release.sh
It uses the aforementioned settings for the release plugin, and more. Features:
- checks if the release is mentioned in the changelog
- checks if there's a remote staging git repository
- asks for the new version number
- opens/closes/promotes releases in repository.apache.org
- generates messages for vote email, announce email
- pushes release candidate to private staging repository
- generates promote and revert scripts
Martijn
On Fri, Aug 19, 2016 at 12:18 PM, Mark Struberg
<st...@yahoo.de.invalid> wrote:
> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
>
> First and important: configure the maven-release-plugin to operate ‚locally‘
> https://github.com/apache/deltaspike/blob/master/pom.xml#L123
>
> The important parts are
> <pushChanges>false</pushChanges>
> <localCheckout>true</localCheckout>
>
> This will configure maven to NOT push you changes upstream to the repo mentioned in the SCM section, but only keep it local.
> And during the release:perform this will also pick up the tag from local.
> That means you need to push it to e.g. github yourself.
>
> Note that in most projects we do _not_ push the release candidate directly to the ASF repo but e.g. to the release managers private github account.
> Reason is that we cannot easily get rid of it from the cannonical ASF repo if the VOTE fails.
> (ASF repos get mirrored downstream in seconds, and while we could technically remove it from our own repo we have no control over all the clones).
>
> This is kind of symetrical to the maven repo staging aproach.
> And the sha1 is the same anyway if we merge the buid-branch to master and push it to the ASF repo later (when the VOTE did pass).
>
> Something very old I wrote up for DeltaSpike a few years ago where I described the steps:
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201309.mbox/%3C1378906506.82251.YahooMailNeo@web28902.mail.ir2.yahoo.com%3E
>
> hth.
>
> LieGrue,
> strub
>
>
>> Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz <bd...@apache.org>:
>>
>> 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?"...
>>
>> I like this - as another example we have
>> http://sling.apache.org/documentation/development/release-management.html
>> in Sling, and as someone who does releases in bursts that's very
>> useful.
>>
>>> ...If there is general consensus on this, I'm happy to draft something to
>>> add to http://incubator.apache.org/guides/graduation.html#releases ...
>>
>> +1 and it's good to add links such as the ones you mentioned and the
>> above if you think they are good examples.
>>
>> 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?
>>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Good links.
I’d like to add some information for projects who use GIT with maven:
First and important: configure the maven-release-plugin to operate ‚locally‘
https://github.com/apache/deltaspike/blob/master/pom.xml#L123
The important parts are
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>
This will configure maven to NOT push you changes upstream to the repo mentioned in the SCM section, but only keep it local.
And during the release:perform this will also pick up the tag from local.
That means you need to push it to e.g. github yourself.
Note that in most projects we do _not_ push the release candidate directly to the ASF repo but e.g. to the release managers private github account.
Reason is that we cannot easily get rid of it from the cannonical ASF repo if the VOTE fails.
(ASF repos get mirrored downstream in seconds, and while we could technically remove it from our own repo we have no control over all the clones).
This is kind of symetrical to the maven repo staging aproach.
And the sha1 is the same anyway if we merge the buid-branch to master and push it to the ASF repo later (when the VOTE did pass).
Something very old I wrote up for DeltaSpike a few years ago where I described the steps:
http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201309.mbox/%3C1378906506.82251.YahooMailNeo@web28902.mail.ir2.yahoo.com%3E
hth.
LieGrue,
strub
> Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
> 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?"...
>
> I like this - as another example we have
> http://sling.apache.org/documentation/development/release-management.html
> in Sling, and as someone who does releases in bursts that's very
> useful.
>
>> ...If there is general consensus on this, I'm happy to draft something to
>> add to http://incubator.apache.org/guides/graduation.html#releases ...
>
> +1 and it's good to add links such as the ones you mentioned and the
> above if you think they are good examples.
>
> 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?
>
> -Bertrand
>
> ---------------------------------------------------------------------
> 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
Re: Ease of release process and exit criteria
Posted by Bertrand Delacretaz <bd...@apache.org>.
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?"...
I like this - as another example we have
http://sling.apache.org/documentation/development/release-management.html
in Sling, and as someone who does releases in bursts that's very
useful.
> ...If there is general consensus on this, I'm happy to draft something to
> add to http://incubator.apache.org/guides/graduation.html#releases ...
+1 and it's good to add links such as the ones you mentioned and the
above if you think they are good examples.
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?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Ease of release process and exit criteria
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Aug 19, 2016 at 2:23 AM, Mark Thomas <ma...@apache.org> wrote:
> Hi,
>
> I've noticed a pattern in some the board reports of PMCs who are
> beginning to experience difficulties. In a notable number of cases a
> significant part of the problem is difficulty in producing a release.
> The sorts of phrases I am seeing are along the lines of releases "are
> too difficult", "take too much effort" or "the person that used to do
> the releases is no longer active". I've seen this in projects of all
> sizes and maturity levels.
>
> I've also experienced this in projects I have been involved in.
> Fortunately, in those cases the community was able to figure out the
> release process, simplify/automate it and document it, reducing the
> future risk to the project.
>
> To put some specifics on this to give an idea of what I am talking
> about. The documented Windows build process for Tomcat Native is this:
>
> http://tomcat.apache.org/native-doc/#Building/Windows
>
> which is fine if you want to test a patch or build it form source to use
> locally but is insufficient to produce a release. What the community
> then produced is this:
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows
>
>
> This got me wondering. Is protecting projects from this sort of future
> problem something that could / should be addressed during incubation?
> 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?"
>
> If there is general consensus on this, I'm happy to draft something to
> add to http://incubator.apache.org/guides/graduation.html#releases
>
> Thoughts?
It is not just documenting it, but having access to all the build environment
the community considers a must for doing a release. Case in point: recently
I've had an opportunity to work with commons community on fixing an issue
in jsvc to enable its build on ARM. Given that this was driven out of
the downstream
requirements my next step was to suggest a patch release and semi-volunteer
as an RM. Then Sebb explained to me that this would require builds on Windows
at which point I had to bow out.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org