[DISCUSS] Creating Project for Release Process Testing...

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Creating Project for Release Process Testing...

James Carman
Why don't we create a real project that we can cut real releases on to
test our release procedures?  Perhaps we can set it up so that it
doesn't sync with central and just gets staged locally.  This way, we
can test out changes to the release process and see how they work.
Also, a new release manager can play around with that project and get
it right before diving into the real work.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

garydgregory
Nice idea, but push it to central to test the whole chain.

G

On Thu, Oct 10, 2013 at 11:24 AM, James Carman
<[hidden email]> wrote:

> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

James Carman
Fine with me!  I'm good with that.  I just was worried folks would
think of it as "cluttering" central


On Thu, Oct 10, 2013 at 11:29 AM, Gary Gregory <[hidden email]> wrote:

> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
> <[hidden email]> wrote:
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Matt Benson-2
In reply to this post by garydgregory
Once it's properly in Nexus, is there any reason to push all the way to
central?

Matt


On Thu, Oct 10, 2013 at 10:29 AM, Gary Gregory <[hidden email]>wrote:

> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
> <[hidden email]> wrote:
> > Why don't we create a real project that we can cut real releases on to
> > test our release procedures?  Perhaps we can set it up so that it
> > doesn't sync with central and just gets staged locally.  This way, we
> > can test out changes to the release process and see how they work.
> > Also, a new release manager can play around with that project and get
> > it right before diving into the real work.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Emmanuel Bourg-3
In reply to this post by James Carman
Le 10/10/2013 17:24, James Carman a écrit :
> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.

I'm not sure to see the need for this. There is no doubt Git is suitable
for releasing our components. I just walked down the release process for
JCI and besides for tagging I didn't have to interact much with SVN (I
didn't use the Maven release plugin).

With Git you would just have to create a branch, and push a commit that
changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
the same.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

James Carman
This isn't to address Git.  This is just in-general a little sandbox
that folks can use to either test out change to the release process
(or documentation) or just have a go at being a release manager before
actually volunteering.  Anyone would be free to cut a release at any
time.


On Thu, Oct 10, 2013 at 11:34 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 10/10/2013 17:24, James Carman a écrit :
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>
> I'm not sure to see the need for this. There is no doubt Git is suitable
> for releasing our components. I just walked down the release process for
> JCI and besides for tagging I didn't have to interact much with SVN (I
> didn't use the Maven release plugin).
>
> With Git you would just have to create a branch, and push a commit that
> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> the same.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Matt Benson-2
In reply to this post by Emmanuel Bourg-3
Emmanuel,
  IMO this goes beyond the SCM question.  Commons releases are painful
(you've just been through the process; do you disagree?) and I submit that
this fact is the reason it takes so long for any of us to muster up the
courage to commit himself to diving into that process with no real idea
when he'll emerge.  Such a project would allow us to generalize and work
out the various "parts" that might be relevant to any Commons project and
could then serve as a cookbook to show how to address various situations.

Matt


On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 10/10/2013 17:24, James Carman a écrit :
> > Why don't we create a real project that we can cut real releases on to
> > test our release procedures?  Perhaps we can set it up so that it
> > doesn't sync with central and just gets staged locally.  This way, we
> > can test out changes to the release process and see how they work.
> > Also, a new release manager can play around with that project and get
> > it right before diving into the real work.
>
> I'm not sure to see the need for this. There is no doubt Git is suitable
> for releasing our components. I just walked down the release process for
> JCI and besides for tagging I didn't have to interact much with SVN (I
> didn't use the Maven release plugin).
>
> With Git you would just have to create a branch, and push a commit that
> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> the same.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Emmanuel Bourg-3
In reply to this post by James Carman
Le 10/10/2013 17:36, James Carman a écrit :
> This isn't to address Git.  This is just in-general a little sandbox
> that folks can use to either test out change to the release process
> (or documentation) or just have a go at being a release manager before
> actually volunteering.  Anyone would be free to cut a release at any
> time.

Ah sure, excellent idea. You may want two projects then, a simple one
and another with modules.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

James Carman
Or just a multi-module only and do the worst case scenario.

On Thu, Oct 10, 2013 at 11:41 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 10/10/2013 17:36, James Carman a écrit :
>> This isn't to address Git.  This is just in-general a little sandbox
>> that folks can use to either test out change to the release process
>> (or documentation) or just have a go at being a release manager before
>> actually volunteering.  Anyone would be free to cut a release at any
>> time.
>
> Ah sure, excellent idea. You may want two projects then, a simple one
> and another with modules.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

James Carman
In reply to this post by Matt Benson-2
I need to have Matt start writing my emails. What he said! ;)  I'm too
impatient to be so eloquent.

On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson <[hidden email]> wrote:

> Emmanuel,
>   IMO this goes beyond the SCM question.  Commons releases are painful
> (you've just been through the process; do you disagree?) and I submit that
> this fact is the reason it takes so long for any of us to muster up the
> courage to commit himself to diving into that process with no real idea
> when he'll emerge.  Such a project would allow us to generalize and work
> out the various "parts" that might be relevant to any Commons project and
> could then serve as a cookbook to show how to address various situations.
>
> Matt
>
>
> On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg <[hidden email]> wrote:
>
>> Le 10/10/2013 17:24, James Carman a écrit :
>> > Why don't we create a real project that we can cut real releases on to
>> > test our release procedures?  Perhaps we can set it up so that it
>> > doesn't sync with central and just gets staged locally.  This way, we
>> > can test out changes to the release process and see how they work.
>> > Also, a new release manager can play around with that project and get
>> > it right before diving into the real work.
>>
>> I'm not sure to see the need for this. There is no doubt Git is suitable
>> for releasing our components. I just walked down the release process for
>> JCI and besides for tagging I didn't have to interact much with SVN (I
>> didn't use the Maven release plugin).
>>
>> With Git you would just have to create a branch, and push a commit that
>> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
>> the same.
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Matt Benson-2
We're all still talking about the release process, but in all honesty I've
not done it for several years at Commons.  I think it would be immensely
helpful for those of us who have been at least part way through the process
fairly recently (Emmanuel, Gary, others?) to present your recollections of
what was difficult, so that we can have a real list of things to try and
address.

Matt


On Thu, Oct 10, 2013 at 10:46 AM, James Carman
<[hidden email]>wrote:

> I need to have Matt start writing my emails. What he said! ;)  I'm too
> impatient to be so eloquent.
>
> On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson <[hidden email]>
> wrote:
> > Emmanuel,
> >   IMO this goes beyond the SCM question.  Commons releases are painful
> > (you've just been through the process; do you disagree?) and I submit
> that
> > this fact is the reason it takes so long for any of us to muster up the
> > courage to commit himself to diving into that process with no real idea
> > when he'll emerge.  Such a project would allow us to generalize and work
> > out the various "parts" that might be relevant to any Commons project and
> > could then serve as a cookbook to show how to address various situations.
> >
> > Matt
> >
> >
> > On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg <[hidden email]>
> wrote:
> >
> >> Le 10/10/2013 17:24, James Carman a écrit :
> >> > Why don't we create a real project that we can cut real releases on to
> >> > test our release procedures?  Perhaps we can set it up so that it
> >> > doesn't sync with central and just gets staged locally.  This way, we
> >> > can test out changes to the release process and see how they work.
> >> > Also, a new release manager can play around with that project and get
> >> > it right before diving into the real work.
> >>
> >> I'm not sure to see the need for this. There is no doubt Git is suitable
> >> for releasing our components. I just walked down the release process for
> >> JCI and besides for tagging I didn't have to interact much with SVN (I
> >> didn't use the Maven release plugin).
> >>
> >> With Git you would just have to create a branch, and push a commit that
> >> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> >> the same.
> >>
> >> Emmanuel Bourg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Stefan Bodewig
On 2013-10-11, Matt Benson wrote:

> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons.  I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanuel, Gary, others?) to present your recollections of
> what was difficult, so that we can have a real list of things to try and
> address.

Not sure whether May is recent enough :-)

AFAIR there isn't anything difficult.  The major pain point for me is
the sheer number of manual steps - with it comes a big number of
opportunities to make mistakes - and the time it takes.

One detail I just figured out after my third release was that I can
start the gpg-agent before running "mvn deploy" - and I think I've
documented that.  Without that I had to type in my passphrase for every
single artifact.

I prefer the "create the tag manually and avoid the release plugin"
approach but don't think there is a big difference here.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Henri Yandell
In reply to this post by James Carman
+1 from me for anything that makes the release process sane.

I'd be committing again if preparing a release was simple enough. As it is,
I don't have the blocks of time needed to push out a release and committing
to projects with no apparent release manager becomes an exercise in
futility.

Hen


On Thu, Oct 10, 2013 at 8:24 AM, James Carman <[hidden email]>wrote:

> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Emmanuel Bourg-3
In reply to this post by Matt Benson-2
Le 11/10/2013 01:35, Matt Benson a écrit :
> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons.  I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanuel, Gary, others?) to present your recollections of
> what was difficult, so that we can have a real list of things to try and
> address.

Here is my quick feed back on the release process. For the record I
prepared the release on Windows by following the 'Using Nexus for
Commons Maven releases' guide [1]. I also took some bits from the
'Releasing Components' guide [2] (unifying these documents would be a
good start).

1. The initial setup is a bit tedious. Generating the GPG key, uploading
it, configuring the agent, adding the Maven settings. This is not fun
and sometimes frustrating (I didn't set my ASF password properly in the
Maven settings and I had to reset it twice. Nexus rejected my uploads
with a 401 error but I didn't figure my account was locked until I found
myself unable to commit a change in SVN). Hopefully all of this is
performed only once.

2. The Nexus UI is a bit confusing when you are not used to it. Between
User Managed Repositories, Nexus Managed Repositories and Staging
Repositories it wasn't obvious at the first glance to see where the
action was supposed to take place. A mini howto with annotated
screenshots would help.

3. Having to drop manually the -src and -bin artifacts uploaded to Nexus
is annoying. I gave up trying to remove the absurd .asc.sha1 and
.asc.md5 files for JCI, there was too many of them (12 files per
artifact, 6 artifacts).

4. Preparing the release notes is time consuming. I know it can be
generated from JIRA but I don't find that descriptive enough. Using the
Maven changes.xml is the best solution, but it has to be maintained
properly during the development (it wasn't for JCI).

5. I created the tag manually, that was simple enough. I don't trust the
release plugin. I guess I need some training on a dummy project. Due to
minor errors spotted afterward I had to recreate the tag twice. So I
suggest creating the tag only when you have reviewed everything and
about to send the vote mail.

6. 'mvn site:stage-deploy' doesn't work. I got the message
"maven.site.deploy.skip = true: Skipping site deployment". This property
is set in the parent pom! I had to tar the site, upload and install it
manually on people.apache.org.

7. I would like a [VOTE] mail generator :)

8. Uploading the source and the binary archives on people.apache.org
implies too many manual steps. This has to be automated (with a Maven
plugin attached to the deploy phase?).


Emmanuel Bourg

[1] http://wiki.apache.org/commons/UsingNexus
[2] http://commons.apache.org/releases/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Gilles Sadowski
In reply to this post by Matt Benson-2
On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:

> We're all still talking about the release process, but in all honesty
> I've
> not done it for several years at Commons.  I think it would be
> immensely
> helpful for those of us who have been at least part way through the
> process
> fairly recently (Emmanuel, Gary, others?) to present your
> recollections of
> what was difficult, so that we can have a real list of things to try
> and
> address.
>

There is a mini-howto for Commons Math here:
   
https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt

The aim was to provide a fool-proof, step-by-step recipe, which the
"official"
Wiki documents were _not_: The missing bits were filled as a summary of
my
interaction with the ML (cf. archive).
[Luc upgraded the document after the CMS change.]

Nothing is "complicated"; following the recipe should allow anyone to
make a
release.
As was noted in another post:
  * several steps could be made faster with scripting
  * removing spurious files from Nexus is a pain after a few RCs


Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Olivier Lamy
In reply to this post by Emmanuel Bourg-3
On 11 October 2013 20:23, Emmanuel Bourg <[hidden email]> wrote:

> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons.  I think it would be immensely
>> helpful for those of us who have been at least part way through the process
>> fairly recently (Emmanuel, Gary, others?) to present your recollections of
>> what was difficult, so that we can have a real list of things to try and
>> address.
>
> Here is my quick feed back on the release process. For the record I
> prepared the release on Windows by following the 'Using Nexus for
> Commons Maven releases' guide [1]. I also took some bits from the
> 'Releasing Components' guide [2] (unifying these documents would be a
> good start).
>
> 1. The initial setup is a bit tedious. Generating the GPG key, uploading
> it, configuring the agent, adding the Maven settings. This is not fun
> and sometimes frustrating (I didn't set my ASF password properly in the
> Maven settings and I had to reset it twice. Nexus rejected my uploads
> with a 401 error but I didn't figure my account was locked until I found
> myself unable to commit a change in SVN). Hopefully all of this is
> performed only once.
>
> 2. The Nexus UI is a bit confusing when you are not used to it. Between
> User Managed Repositories, Nexus Managed Repositories and Staging
> Repositories it wasn't obvious at the first glance to see where the
> action was supposed to take place. A mini howto with annotated
> screenshots would help.
>
> 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus
> is annoying. I gave up trying to remove the absurd .asc.sha1 and
> .asc.md5 files for JCI, there was too many of them (12 files per
> artifact, 6 artifacts).

Why removing those files? It's is strictly forbidden by any Apache
rules to have those?

>
> 4. Preparing the release notes is time consuming. I know it can be
> generated from JIRA but I don't find that descriptive enough. Using the
> Maven changes.xml is the best solution, but it has to be maintained
> properly during the development (it wasn't for JCI).
>
> 5. I created the tag manually, that was simple enough. I don't trust the
> release plugin. I guess I need some training on a dummy project. Due to
> minor errors spotted afterward I had to recreate the tag twice. So I
> suggest creating the tag only when you have reviewed everything and
> about to send the vote mail.

why creating tag manually? I believe release plugin does it.

>
> 6. 'mvn site:stage-deploy' doesn't work. I got the message
> "maven.site.deploy.skip = true: Skipping site deployment". This property
> is set in the parent pom! I had to tar the site, upload and install it
> manually on people.apache.org.

probably something not complicated to fix.

>
> 7. I would like a [VOTE] mail generator :)

Agree too.

>
> 8. Uploading the source and the binary archives on people.apache.org
> implies too many manual steps. This has to be automated (with a Maven
> plugin attached to the deploy phase?).
>

Agree too (something I wanted to do but not having time to work on it).

I don't understand why you guys are adding manual steps (whereas tools exists).

>
> Emmanuel Bourg
>
> [1] http://wiki.apache.org/commons/UsingNexus
> [2] http://commons.apache.org/releases/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Siegfried Goeschl
In reply to this post by garydgregory
+1 on that

I did a few releases over the year and had ALWAYS issues - for me the
biggest obstacles are

* getting a positive vote on a RC (that's a different story)
* getting the release out of the door - a test project would help
immensely since I can blow it up without any consequences

Cheers,

Siegfried Goeschl

On 10.10.13 17:29, Gary Gregory wrote:

> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
> <[hidden email]> wrote:
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

James Carman
JIRA created:

https://issues.apache.org/jira/browse/INFRA-6859


On Sun, Oct 13, 2013 at 4:17 AM, Siegfried Goeschl
<[hidden email]> wrote:

> +1 on that
>
> I did a few releases over the year and had ALWAYS issues - for me the
> biggest obstacles are
>
> * getting a positive vote on a RC (that's a different story)
> * getting the release out of the door - a test project would help immensely
> since I can blow it up without any consequences
>
> Cheers,
>
> Siegfried Goeschl
>
>
> On 10.10.13 17:29, Gary Gregory wrote:
>>
>> Nice idea, but push it to central to test the whole chain.
>>
>> G
>>
>> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
>> <[hidden email]> wrote:
>>>
>>> Why don't we create a real project that we can cut real releases on to
>>> test our release procedures?  Perhaps we can set it up so that it
>>> doesn't sync with central and just gets staged locally.  This way, we
>>> can test out changes to the release process and see how they work.
>>> Also, a new release manager can play around with that project and get
>>> it right before diving into the real work.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Phil Steitz
In reply to this post by Gilles Sadowski
On 10/11/13 3:53 AM, Gilles wrote:

> On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
>> We're all still talking about the release process, but in all
>> honesty I've
>> not done it for several years at Commons.  I think it would be
>> immensely
>> helpful for those of us who have been at least part way through
>> the process
>> fairly recently (Emmanuel, Gary, others?) to present your
>> recollections of
>> what was difficult, so that we can have a real list of things to
>> try and
>> address.
>>
>
> There is a mini-howto for Commons Math here:
>  
> https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt
>
> The aim was to provide a fool-proof, step-by-step recipe, which
> the "official"
> Wiki documents were _not_: The missing bits were filled as a
> summary of my
> interaction with the ML (cf. archive).
> [Luc upgraded the document after the CMS change.]
>
> Nothing is "complicated"; following the recipe should allow anyone
> to make a
> release.
> As was noted in another post:
>  * several steps could be made faster with scripting

+1 and once again THANKs for documenting this stuff for [math],
Gilles.  I have not cut a release since the forced Nexus days, but
before then, I always used shell scripts that I eventually committed
to svn to make it "just push the button" the next time I did it.  An
example is [1], which no longer works due to changes in commons
parent, maven plugins and the Nexus requirement; but if and when I
cut another release there or on anything else, I will likely just
update it so .(n+k) are easy.  After doing the work to create [1]
for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with
this approach is that it requires a unix shell and it also punts the
"let maven automagially do everything" desire.  Personally, I much
prefer the srcipt approach as I know exactly what is happening.

This brings up another point that has been sort of in the background
here.  I don't think it is a defeat to have individual components
have their own RM READMEs.  Trying to solve the problem generically
for all components increases the degree of difficulty and the
probability that people will run into little problems.  I have felt
this way for a long time regarding the commons parent pom as well.
It might be better to destandardize a little, slim down the parent
(or dump it altogether) and allow component RMs to develop things
like [1] and Gilles' instructions above, without aiming to solve the
problem generically for all components.  When you think about it,
what we have have been struggling with here is generic release
tooling for java components @apache, which is in theory possible,
but with sometimes flaky and changing underlying tools (maven
plugins, nexus) and little edge cases to consider at the component
level, we end up burning ridiculously more energy and having to
fiddle more often than if we just maintained little scripts/READMEs
at the component level.  We could maintain general instructions
explaining what is *required* and just use the time honored Commons
tradition of imitating other components to get and keep the
individual RC scripts working.  As a concrete example, I would like
to see us experiment with the tomcat approach to deployment [2] for
pool2 and dbcp2, but I don't want to force everyone down this path
or get everyone to agree to it.

Phil

[1]
https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh
[2] http://markmail.org/message/kkualb7xse2mcwkd

>  * removing spurious files from Nexus is a pain after a few RCs
>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Creating Project for Release Process Testing...

Matt Benson-2
I understand your frustration, Phil, particularly if you're the type who
has never liked the flavor of the Maven kool-aid... I know I struggled
fruitlessly for years against Maven! However, the biggest benefit I see to
the parent pom is the site management.  I can't justify us propping up some
custom site management solution, personally. I suppose that if we can get
the Maven fluido skin working and agree on a bootstrap style, it could
become an option for a given component to use the straight CMS with that
style and bypass the Maven site. But I do think some measure of cosmetic
unity among the component sites should be maintained.

Matt
On Oct 13, 2013 12:20 PM, "Phil Steitz" <[hidden email]> wrote:

> On 10/11/13 3:53 AM, Gilles wrote:
> > On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
> >> We're all still talking about the release process, but in all
> >> honesty I've
> >> not done it for several years at Commons.  I think it would be
> >> immensely
> >> helpful for those of us who have been at least part way through
> >> the process
> >> fairly recently (Emmanuel, Gary, others?) to present your
> >> recollections of
> >> what was difficult, so that we can have a real list of things to
> >> try and
> >> address.
> >>
> >
> > There is a mini-howto for Commons Math here:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt
> >
> > The aim was to provide a fool-proof, step-by-step recipe, which
> > the "official"
> > Wiki documents were _not_: The missing bits were filled as a
> > summary of my
> > interaction with the ML (cf. archive).
> > [Luc upgraded the document after the CMS change.]
> >
> > Nothing is "complicated"; following the recipe should allow anyone
> > to make a
> > release.
> > As was noted in another post:
> >  * several steps could be made faster with scripting
>
> +1 and once again THANKs for documenting this stuff for [math],
> Gilles.  I have not cut a release since the forced Nexus days, but
> before then, I always used shell scripts that I eventually committed
> to svn to make it "just push the button" the next time I did it.  An
> example is [1], which no longer works due to changes in commons
> parent, maven plugins and the Nexus requirement; but if and when I
> cut another release there or on anything else, I will likely just
> update it so .(n+k) are easy.  After doing the work to create [1]
> for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with
> this approach is that it requires a unix shell and it also punts the
> "let maven automagially do everything" desire.  Personally, I much
> prefer the srcipt approach as I know exactly what is happening.
>
> This brings up another point that has been sort of in the background
> here.  I don't think it is a defeat to have individual components
> have their own RM READMEs.  Trying to solve the problem generically
> for all components increases the degree of difficulty and the
> probability that people will run into little problems.  I have felt
> this way for a long time regarding the commons parent pom as well.
> It might be better to destandardize a little, slim down the parent
> (or dump it altogether) and allow component RMs to develop things
> like [1] and Gilles' instructions above, without aiming to solve the
> problem generically for all components.  When you think about it,
> what we have have been struggling with here is generic release
> tooling for java components @apache, which is in theory possible,
> but with sometimes flaky and changing underlying tools (maven
> plugins, nexus) and little edge cases to consider at the component
> level, we end up burning ridiculously more energy and having to
> fiddle more often than if we just maintained little scripts/READMEs
> at the component level.  We could maintain general instructions
> explaining what is *required* and just use the time honored Commons
> tradition of imitating other components to get and keep the
> individual RC scripts working.  As a concrete example, I would like
> to see us experiment with the tomcat approach to deployment [2] for
> pool2 and dbcp2, but I don't want to force everyone down this path
> or get everyone to agree to it.
>
> Phil
>
> [1]
> https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh
> [2] http://markmail.org/message/kkualb7xse2mcwkd
>
> >  * removing spurious files from Nexus is a pain after a few RCs
> >
> >
> > Regards,
> > Gilles
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12