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 he
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 previ
+1
In practice this is often really a problem with many projects :/
LieGrue,
strub
> On Wednesday, 28 September 2016, 10:41, Mark Thomas 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
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 d
On Tue, Aug 23, 2016 at 2:02 PM, Ted Dunning 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.
-
;
> dennis.hamil...@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.
> >>>
ng 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-
>>>>
6, 17:41, Dennis E. Hamilton
> wrote:
> >
>
>> -Original Message-
>> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
>> Sent: Friday, August 19, 2016 03:19
>> To: general@incubator.apache.org
>> Subject: Re: Ease of release process a
On 8/20/16, 11:16 PM, "Christopher" 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 friv
l 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
> >>> 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
>>>
>>>> -O
>> +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: S
On Fri, Aug 19, 2016 at 2:23 AM, Mark Thomas 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
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
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 A
Message-
>> From: Shane Curcuru [mailto:a...@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 M
On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg
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 i
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
> wrote:
> >> ...I'm think
> -Original Message-
> From: Mark Struberg [mailto:strub...@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 informati
On 8/19/16, 7:08 AM, "Shane Curcuru" wrote:
>Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
>> Hi Mark,
>>
>> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas wrote:
>>> ...I'm thinking of a graduation criteria long the lines of:
>>> "Is the release process clearly documented to the point that so
Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> Hi Mark,
>
> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 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 bu
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 settin
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
wrote:
> Good links.
>
> I’d
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
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
false
true
This will configure maven to NOT push
Hi Mark,
On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 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
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", "tak
27 matches
Mail list logo
