You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2013/10/08 18:46:34 UTC
[DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Hi,
one of the points that seem to always come up once in a while is the
process of releasing components. I've never done it myself so I'm asking
people who have done it:
What are the problems and how can we make releasing easier?
Is the complexity of the parent pom a problem? (Do we really need all the
stuff that is declared there?)
Is there a way to automate all the stuff that needs to be done in a
portable way?
Would it be possible to automate release for example on a Jenkins instance?
Benedikt
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Posted by Woonsan Ko <wo...@yahoo.com>.
I think I understand what Gary means.
I once wrote down the process to release Apache Portals Application for other PMC members here:
- http://wiki.apache.org/portals/Applications/Release_Process
I guess the process is almost the same in other projects (log4j2 or possibly lang).
There are many time consuming / error-prone steps like Gary mentioned. I have no idea on how we can possibly improve the process though.
Regards,
Woonsan
----- Original Message -----
> From: Gary Gregory <ga...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Tuesday, October 8, 2013 2:10 PM
> Subject: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
>
> Luckily, Ralph handles release manager duties, for which I am
> grateful. So I cannot speak to the ease or difficulty of the process
> there.
>
> Gary
>
> On Oct 8, 2013, at 14:08, Benedikt Ritter <be...@gmail.com> wrote:
>
>> Hey Gary,
>>
>> you are involved in other projects (like log4j2) how do they do it? Is it
> easier to release log4j2 than it is to release for example [lang]?
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 08.10.2013 um 19:52 schrieb Gary Gregory
> <ga...@gmail.com>:
>>>
>>> IMO the problems are dealing with Nexus, a web site, and a
> 'dist'
>>> directory; that THREE things to get just right, none are 100%
> automated.
>>> With Nexus you have to do some manual steps. If you look at all the
>>> instructions for any commons component, it is long, a combo of manual
> and
>>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>>
>>> Gary
>>>
>>>
>>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter
> <br...@apache.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> one of the points that seem to always come up once in a while is
> the
>>>> process of releasing components. I've never done it myself so
> I'm asking
>>>> people who have done it:
>>>>
>>>> What are the problems and how can we make releasing easier?
>>>> Is the complexity of the parent pom a problem? (Do we really need
> all the
>>>> stuff that is declared there?)
>>>> Is there a way to automate all the stuff that needs to be done in a
>>>> portable way?
>>>> Would it be possible to automate release for example on a Jenkins
> instance?
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second
> Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition
> <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Gary Gregory <ga...@gmail.com>.
Luckily, Ralph handles release manager duties, for which I am
grateful. So I cannot speak to the ease or difficulty of the process
there.
Gary
On Oct 8, 2013, at 14:08, Benedikt Ritter <be...@gmail.com> wrote:
> Hey Gary,
>
> you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]?
>
> Benedikt
>
> Send from my mobile device
>
>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <ga...@gmail.com>:
>>
>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>> directory; that THREE things to get just right, none are 100% automated.
>> With Nexus you have to do some manual steps. If you look at all the
>> instructions for any commons component, it is long, a combo of manual and
>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>
>> Gary
>>
>>
>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <br...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> one of the points that seem to always come up once in a while is the
>>> process of releasing components. I've never done it myself so I'm asking
>>> people who have done it:
>>>
>>> What are the problems and how can we make releasing easier?
>>> Is the complexity of the parent pom a problem? (Do we really need all the
>>> stuff that is declared there?)
>>> Is there a way to automate all the stuff that needs to be done in a
>>> portable way?
>>> Would it be possible to automate release for example on a Jenkins instance?
>>>
>>> Benedikt
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Mark Thomas <ma...@apache.org>.
On 14/10/2013 05:26, Stefan Bodewig wrote:
> On 2013-10-14, sebb wrote:
>
>> On 9 October 2013 05:43, Stefan Bodewig <bo...@apache.org> wrote:
>
>>> why vote on Nexus staged artifacts if the tarball is fine? I'm not
>>> talking about releasing to MC directly but rather about not pushing
>>> anything to Nexus before the vote on the tarball has passed. This could
>>> reduce the release process to tagging and publishing the tarballs before
>>> the vote.
>
>> So where are you going to publish the tarballs?
>
> dist svn
>
>> At some point the tarballs are going to have to end up on Nexus
>> anyway, so why not use it?
>
> Not the tarballs, only the "maven artifacts" which I'd extract/build
> from the tarballs. I'd just delay that until after the vote. Not sure
> whether this is viable, and maybe it is just my poor network bandwidth
> talking here but the actual act of uploading the artifacts eats up more
> than half of the time of creating a RC and I'd like to avoid the wasted
> time for RCs who's vote fails.
That makes sense. Vote on the source release and then generate the
convenience binaries.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-14, sebb wrote:
> On 9 October 2013 05:43, Stefan Bodewig <bo...@apache.org> wrote:
>> why vote on Nexus staged artifacts if the tarball is fine? I'm not
>> talking about releasing to MC directly but rather about not pushing
>> anything to Nexus before the vote on the tarball has passed. This could
>> reduce the release process to tagging and publishing the tarballs before
>> the vote.
> So where are you going to publish the tarballs?
dist svn
> At some point the tarballs are going to have to end up on Nexus
> anyway, so why not use it?
Not the tarballs, only the "maven artifacts" which I'd extract/build
from the tarballs. I'd just delay that until after the vote. Not sure
whether this is viable, and maybe it is just my poor network bandwidth
talking here but the actual act of uploading the artifacts eats up more
than half of the time of creating a RC and I'd like to avoid the wasted
time for RCs who's vote fails.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by sebb <se...@gmail.com>.
On 9 October 2013 05:43, Stefan Bodewig <bo...@apache.org> wrote:
> On 2013-10-08, Benedikt Ritter wrote:
>
>> you are involved in other projects (like log4j2) how do they do it? Is
>> it easier to release log4j2 than it is to release for example [lang]?
>
> Over the past year I've cut releases at the ASF for Commons Compress,
> Ant and log4net and outside of the ASF of a small company sponsored QMQP
> library at github and XMLUnit at sourceforge.
>
> The QMQP lib was trivial to release because I didn't have to vote,
> didn't intend to have a proper distribution outside of MC and the only
> site is the Readme.md. This wouldn't be possible for anything
> non-trivial. Still there was a Nexus between my command line and Maven
> central and it's been more than a single step.
>
> All ASF releases and XMLUnit have been similar - it is always a painful
> manual process. Create a tag, build the stuff upload to Nexus (not for
> log4net), upload non Maven-distributables, update site. In XMLUnit I
> can skip the votes, but I don't see how to make anything of this a lot
> easier.
>
> As long as we think we have to distribute things to three places and
> vote on all of them, I don't see how to simplify things. I must admit
> I'm not sure we actually have to do that, we can change the site as
> often as we want to, so why vote on it?
I don't think we do vote on it; it's provided for convenience and for
people to review for obvious omissions.
> And we can trust our tooling,
Sorry, but that is not the case.
There are lots of ways that the build process can break.
I was assured categorically on the Maven dev list that their release
process was fool-proof.
Several releases were later found to have spurious files in the source bundles.
> why vote on Nexus staged artifacts if the tarball is fine? I'm not
> talking about releasing to MC directly but rather about not pushing
> anything to Nexus before the vote on the tarball has passed. This could
> reduce the release process to tagging and publishing the tarballs before
> the vote.
So where are you going to publish the tarballs?
At some point the tarballs are going to have to end up on Nexus
anyway, so why not use it?
> At work I've been cutting releases for stuff built from 15 git repos
> every two weeks - at the end of scrum sprints. We've automated things
> so far that it is mostly down to tagging the repositories and the rest
> is done by CI.
>
> But there are things the build process doesn't do and that cannot be
> automated for good reasons - PGP signing for example. I wouldn't want
> to put a private key on a CI machine, or rather I wouldn't trust a key
> that lived on such a machine.
ASF infra would not allow that.
> In addition I probably wouldn't trust the artifacts built on a public CI
> machine that is open to as many people as our Jenkins either - it would
> be a beautiful target for attacks and a great resource for publishing
> backdoored releases if we were to rely on CI to build our releases.
Indeed.
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-08, Benedikt Ritter wrote:
> you are involved in other projects (like log4j2) how do they do it? Is
> it easier to release log4j2 than it is to release for example [lang]?
Over the past year I've cut releases at the ASF for Commons Compress,
Ant and log4net and outside of the ASF of a small company sponsored QMQP
library at github and XMLUnit at sourceforge.
The QMQP lib was trivial to release because I didn't have to vote,
didn't intend to have a proper distribution outside of MC and the only
site is the Readme.md. This wouldn't be possible for anything
non-trivial. Still there was a Nexus between my command line and Maven
central and it's been more than a single step.
All ASF releases and XMLUnit have been similar - it is always a painful
manual process. Create a tag, build the stuff upload to Nexus (not for
log4net), upload non Maven-distributables, update site. In XMLUnit I
can skip the votes, but I don't see how to make anything of this a lot
easier.
As long as we think we have to distribute things to three places and
vote on all of them, I don't see how to simplify things. I must admit
I'm not sure we actually have to do that, we can change the site as
often as we want to, so why vote on it? And we can trust our tooling,
why vote on Nexus staged artifacts if the tarball is fine? I'm not
talking about releasing to MC directly but rather about not pushing
anything to Nexus before the vote on the tarball has passed. This could
reduce the release process to tagging and publishing the tarballs before
the vote.
At work I've been cutting releases for stuff built from 15 git repos
every two weeks - at the end of scrum sprints. We've automated things
so far that it is mostly down to tagging the repositories and the rest
is done by CI.
But there are things the build process doesn't do and that cannot be
automated for good reasons - PGP signing for example. I wouldn't want
to put a private key on a CI machine, or rather I wouldn't trust a key
that lived on such a machine.
In addition I probably wouldn't trust the artifacts built on a public CI
machine that is open to as many people as our Jenkins either - it would
be a beautiful target for attacks and a great resource for publishing
backdoored releases if we were to rely on CI to build our releases.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Posted by Ralph Goers <ra...@dslextreme.com>.
I wrote the Log4j2 wiki page just so I could remember and repeat the few manual steps I have to do for each release. The difficulty is getting the bugs out of the first release. Log4j 2 still has some difficulties though around its build process primarily because none of us are OSGi experts and we know that what we are building isn't correct for that. When you factor in trying to build stuff so that it works in Google App Engine, Android, various JDK versions and vendors then things start to become more difficult. On that though, my attitude has always been to build and test for the environments I use and let people who work in other environments test and provide fixes for theirs, at least as much as possible.
However, the primary goal of a release is to have a source distribution that meets the legal obligations as stated by the ASF. There is no requirement to build and ship binaries - we do that as a convenience for our users and because we know we will get lots of complaints if we don't.
Ralph
On Oct 8, 2013, at 11:44 AM, Christian Grobmeier wrote:
> On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:
>
>> Hey Gary,
>>
>> you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]?
>
> Check this guide:
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>
> In fact we have an ASF maven pom:
> http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml
> This is extended by tons of plugins and other things and called "commons parent pom". The commons parent pom does a lot of things, and all components are more or less required to run the same way.
>
> The question is, why should a component not be independent from commons-parent-pom and decide on it's on? With having the ASF-parent only releasing could be:
>
> mvn release:prepare release:perform
>
> Then everything should be on Nexus.
>
> I know this is a controverse question. But as people can download the artifacts directly from nexus if they wish - including source, LICENSE, NOTICE and all that… why are we bothering to put on any other place?
> One could see at as: we release source code, as we create a tag. For convenience we put it on Nexus. Nothing else.
>
> For site: I think components should be free to chose on their own. I was thinking different in the past. But now I believe we should just have a front page listing our components like we have here:
> http://logging.apache.org
> …and that site should link to the appropriate sub component site. How it looks or works or how it is build should be decided by the component maintainers independently.
>
> Cheers
> Christian
>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <ga...@gmail.com>:
>>>
>>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>>> directory; that THREE things to get just right, none are 100% automated.
>>> With Nexus you have to do some manual steps. If you look at all the
>>> instructions for any commons component, it is long, a combo of manual and
>>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>>
>>> Gary
>>>
>>>
>>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <br...@apache.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>>>
>>>> What are the problems and how can we make releasing easier?
>>>> Is the complexity of the parent pom a problem? (Do we really need all the
>>>> stuff that is declared there?)
>>>> Is there a way to automate all the stuff that needs to be done in a
>>>> portable way?
>>>> Would it be possible to automate release for example on a Jenkins instance?
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by sebb <se...@gmail.com>.
On 8 October 2013 19:44, Christian Grobmeier <gr...@gmail.com> wrote:
> On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:
>
>> Hey Gary,
>>
>> you are involved in other projects (like log4j2) how do they do it? Is it
>> easier to release log4j2 than it is to release for example [lang]?
>
>
> Check this guide:
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>
> In fact we have an ASF maven pom:
> http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml
> This is extended by tons of plugins and other things and called "commons
> parent pom". The commons parent pom does a lot of things, and all components
> are more or less required to run the same way.
>
> The question is, why should a component not be independent from
> commons-parent-pom and decide on it's on? With having the ASF-parent only
> releasing could be:
>
> mvn release:prepare release:perform
Or equally using the package / deploy manual version.
> Then everything should be on Nexus.
>
> I know this is a controverse question. But as people can download the
> artifacts directly from nexus if they wish - including source, LICENSE,
> NOTICE and all that… why are we bothering to put on any other place?
If you are referring to staging for the release vote, then I agree,
it's not necessary to use another area.
But for formal ASF releases, these must be done via www.apache.org/dist/commons
> One could see at as: we release source code, as we create a tag. For
> convenience we put it on Nexus. Nothing else.
No - Nexus is the only way to release components to Maven Central;
it's not possible to publish jars to MC independently.
(With good reason - there were several accidental 'releases' before
Nexus was introduced).
> For site: I think components should be free to chose on their own. I was
> thinking different in the past. But now I believe we should just have a
> front page listing our components like we have here:
> http://logging.apache.org
> …and that site should link to the appropriate sub component site. How it
> looks or works or how it is build should be decided by the component
> maintainers independently.
OK by me, so long as the ASF branding etc. requirements are met.
> Cheers
> Christian
>
>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <ga...@gmail.com>:
>>>
>>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>>> directory; that THREE things to get just right, none are 100% automated.
>>> With Nexus you have to do some manual steps. If you look at all the
>>> instructions for any commons component, it is long, a combo of manual and
>>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>>
>>> Gary
>>>
>>>
>>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <br...@apache.org>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>>>
>>>> What are the problems and how can we make releasing easier?
>>>> Is the complexity of the parent pom a problem? (Do we really need all
>>>> the
>>>> stuff that is declared there?)
>>>> Is there a way to automate all the stuff that needs to be done in a
>>>> portable way?
>>>> Would it be possible to automate release for example on a Jenkins
>>>> instance?
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second
>>> Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Christian Grobmeier <gr...@gmail.com>.
On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:
> Hey Gary,
>
> you are involved in other projects (like log4j2) how do they do it? Is
> it easier to release log4j2 than it is to release for example [lang]?
Check this guide:
http://wiki.apache.org/logging/Log4j2ReleaseGuide
In fact we have an ASF maven pom:
http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml
This is extended by tons of plugins and other things and called "commons
parent pom". The commons parent pom does a lot of things, and all
components are more or less required to run the same way.
The question is, why should a component not be independent from
commons-parent-pom and decide on it's on? With having the ASF-parent
only releasing could be:
mvn release:prepare release:perform
Then everything should be on Nexus.
I know this is a controverse question. But as people can download the
artifacts directly from nexus if they wish - including source, LICENSE,
NOTICE and all that… why are we bothering to put on any other place?
One could see at as: we release source code, as we create a tag. For
convenience we put it on Nexus. Nothing else.
For site: I think components should be free to chose on their own. I was
thinking different in the past. But now I believe we should just have a
front page listing our components like we have here:
http://logging.apache.org
…and that site should link to the appropriate sub component site. How
it looks or works or how it is build should be decided by the component
maintainers independently.
Cheers
Christian
> Benedikt
>
> Send from my mobile device
>
>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <ga...@gmail.com>:
>>
>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>> directory; that THREE things to get just right, none are 100%
>> automated.
>> With Nexus you have to do some manual steps. If you look at all the
>> instructions for any commons component, it is long, a combo of manual
>> and
>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>
>> Gary
>>
>>
>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter
>>> <br...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> one of the points that seem to always come up once in a while is the
>>> process of releasing components. I've never done it myself so I'm
>>> asking
>>> people who have done it:
>>>
>>> What are the problems and how can we make releasing easier?
>>> Is the complexity of the parent pom a problem? (Do we really need
>>> all the
>>> stuff that is declared there?)
>>> Is there a way to automate all the stuff that needs to be done in a
>>> portable way?
>>> Would it be possible to automate release for example on a Jenkins
>>> instance?
>>>
>>> Benedikt
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second
>> Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Posted by Benedikt Ritter <be...@gmail.com>.
Hey Gary,
you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]?
Benedikt
Send from my mobile device
> Am 08.10.2013 um 19:52 schrieb Gary Gregory <ga...@gmail.com>:
>
> IMO the problems are dealing with Nexus, a web site, and a 'dist'
> directory; that THREE things to get just right, none are 100% automated.
> With Nexus you have to do some manual steps. If you look at all the
> instructions for any commons component, it is long, a combo of manual and
> Maven+Nexus magic and error prone. It is not fun and a barrier.
>
> Gary
>
>
>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <br...@apache.org> wrote:
>>
>> Hi,
>>
>> one of the points that seem to always come up once in a while is the
>> process of releasing components. I've never done it myself so I'm asking
>> people who have done it:
>>
>> What are the problems and how can we make releasing easier?
>> Is the complexity of the parent pom a problem? (Do we really need all the
>> stuff that is declared there?)
>> Is there a way to automate all the stuff that needs to be done in a
>> portable way?
>> Would it be possible to automate release for example on a Jenkins instance?
>>
>> Benedikt
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Gary Gregory <ga...@gmail.com>.
IMO the problems are dealing with Nexus, a web site, and a 'dist'
directory; that THREE things to get just right, none are 100% automated.
With Nexus you have to do some manual steps. If you look at all the
instructions for any commons component, it is long, a combo of manual and
Maven+Nexus magic and error prone. It is not fun and a barrier.
Gary
On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <br...@apache.org> wrote:
> Hi,
>
> one of the points that seem to always come up once in a while is the
> process of releasing components. I've never done it myself so I'm asking
> people who have done it:
>
> What are the problems and how can we make releasing easier?
> Is the complexity of the parent pom a problem? (Do we really need all the
> stuff that is declared there?)
> Is there a way to automate all the stuff that needs to be done in a
> portable way?
> Would it be possible to automate release for example on a Jenkins instance?
>
> Benedikt
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [JCI] Problem with release profile
Posted by Emmanuel Bourg <eb...@apache.org>.
I made some progress but I still have an issue with 'mvn site', see
http://apaste.info/pOvS
Again, any idea is welcome.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JCI] Problem with release profile
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/10/2013 20:06, Benedikt Ritter a écrit :
> Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow.
Could this be caused by the fact that jci is a multi module project?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JCI] Problem with release profile
Posted by sebb <se...@gmail.com>.
On 9 October 2013 14:06, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 08/10/2013 21:25, sebb a écrit :
>
>> Note: we must update Javadoc plugin to the latest version to ensure
>> that the scripting bug is fixed.
>
> Done
>
>> I expect there are several parts of the main pom that can be removed
>> as the parent pom defines all the common stuff that it can.
>
> I cleaned up the pom as much as I could, but most reporting plugins
> still have to be redeclared to specify the aggregate property.
Maybe there's some way that could be added to the parent pom?
Perhaps via a property that defaults to an appropriate setting for
components that _don't_ have modules (the most common case in
Commons).
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JCI] Problem with release profile
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/10/2013 21:25, sebb a écrit :
> Note: we must update Javadoc plugin to the latest version to ensure
> that the scripting bug is fixed.
Done
> I expect there are several parts of the main pom that can be removed
> as the parent pom defines all the common stuff that it can.
I cleaned up the pom as much as I could, but most reporting plugins
still have to be redeclared to specify the aggregate property.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is
releasing such a pain and what can we do to make it easier?)
Posted by sebb <se...@gmail.com>.
Yes.
On 8 October 2013 20:40, Benedikt Ritter <br...@apache.org> wrote:
> Do you have included the latest commons parent pom?
>
>
> 2013/10/8 sebb <se...@gmail.com>
>
>> On 8 October 2013 19:06, Benedikt Ritter <be...@gmail.com> wrote:
>> > Maybe it's a problem with the maven-bundle-plugin. It should generate
>> the Manifest for you. I'm on my mobile right now and will not have the time
>> to have a look until tomorrow.
>>
>> It's not only the osgi Manifest.
>>
>> I tried copying an existing Manifest, and the build process failed with:
>>
>> [INFO] Error for project: Apache Commons JCI FileAlterationMonitor
>> (during package)
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Failed to create assembly: Error creating assembly archive bin:
>> You must set at least one file.
>>
>> The problems are probably due to the use of multiple modules, which
>> are (much) harder to set up.
>>
>> However, there are other commons components with multiple modules; it
>> should be possible to get some clues from them.
>>
>> Note: we must update Javadoc plugin to the latest version to ensure
>> that the scripting bug is fixed.
>>
>> I expect there are several parts of the main pom that can be removed
>> as the parent pom defines all the common stuff that it can.
>>
>> > Benedikt
>> >
>> > Send from my mobile device
>> >
>> >> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <eb...@apache.org>:
>> >>
>> >> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
>> >>
>> >>> What are the problems and how can we make releasing easier?
>> >>
>> >> I have a real example with JCI. I get an error when running the release
>> >> profile with "mvn package -DskipTests -Prelease" :
>> >>
>> >> [INFO] ----------------------------------------------------
>> >> [ERROR] BUILD ERROR
>> >> [INFO] ----------------------------------------------------
>> >> [INFO] Error assembling JAR
>> >>
>> >> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
>> >> does not exist.
>> >>
>> >>
>> >> Any idea?
>> >>
>> >> Emmanuel Bourg
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is
releasing such a pain and what can we do to make it easier?)
Posted by Benedikt Ritter <br...@apache.org>.
Do you have included the latest commons parent pom?
2013/10/8 sebb <se...@gmail.com>
> On 8 October 2013 19:06, Benedikt Ritter <be...@gmail.com> wrote:
> > Maybe it's a problem with the maven-bundle-plugin. It should generate
> the Manifest for you. I'm on my mobile right now and will not have the time
> to have a look until tomorrow.
>
> It's not only the osgi Manifest.
>
> I tried copying an existing Manifest, and the build process failed with:
>
> [INFO] Error for project: Apache Commons JCI FileAlterationMonitor
> (during package)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to create assembly: Error creating assembly archive bin:
> You must set at least one file.
>
> The problems are probably due to the use of multiple modules, which
> are (much) harder to set up.
>
> However, there are other commons components with multiple modules; it
> should be possible to get some clues from them.
>
> Note: we must update Javadoc plugin to the latest version to ensure
> that the scripting bug is fixed.
>
> I expect there are several parts of the main pom that can be removed
> as the parent pom defines all the common stuff that it can.
>
> > Benedikt
> >
> > Send from my mobile device
> >
> >> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <eb...@apache.org>:
> >>
> >> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
> >>
> >>> What are the problems and how can we make releasing easier?
> >>
> >> I have a real example with JCI. I get an error when running the release
> >> profile with "mvn package -DskipTests -Prelease" :
> >>
> >> [INFO] ----------------------------------------------------
> >> [ERROR] BUILD ERROR
> >> [INFO] ----------------------------------------------------
> >> [INFO] Error assembling JAR
> >>
> >> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
> >> does not exist.
> >>
> >>
> >> Any idea?
> >>
> >> Emmanuel Bourg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [JCI] Problem with release profile
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/10/2013 21:25, sebb a écrit :
> However, there are other commons components with multiple modules; it
> should be possible to get some clues from them.
Thank you for the suggestion, I found the solution in vfs.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is
releasing such a pain and what can we do to make it easier?)
Posted by sebb <se...@gmail.com>.
On 8 October 2013 19:06, Benedikt Ritter <be...@gmail.com> wrote:
> Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow.
It's not only the osgi Manifest.
I tried copying an existing Manifest, and the build process failed with:
[INFO] Error for project: Apache Commons JCI FileAlterationMonitor
(during package)
[INFO] ------------------------------------------------------------------------
[INFO] Failed to create assembly: Error creating assembly archive bin:
You must set at least one file.
The problems are probably due to the use of multiple modules, which
are (much) harder to set up.
However, there are other commons components with multiple modules; it
should be possible to get some clues from them.
Note: we must update Javadoc plugin to the latest version to ensure
that the scripting bug is fixed.
I expect there are several parts of the main pom that can be removed
as the parent pom defines all the common stuff that it can.
> Benedikt
>
> Send from my mobile device
>
>> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <eb...@apache.org>:
>>
>> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
>>
>>> What are the problems and how can we make releasing easier?
>>
>> I have a real example with JCI. I get an error when running the release
>> profile with "mvn package -DskipTests -Prelease" :
>>
>> [INFO] ----------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO] ----------------------------------------------------
>> [INFO] Error assembling JAR
>>
>> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
>> does not exist.
>>
>>
>> Any idea?
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)
Posted by Benedikt Ritter <be...@gmail.com>.
Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow.
Benedikt
Send from my mobile device
> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <eb...@apache.org>:
>
> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
>
>> What are the problems and how can we make releasing easier?
>
> I have a real example with JCI. I get an error when running the release
> profile with "mvn package -DskipTests -Prelease" :
>
> [INFO] ----------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ----------------------------------------------------
> [INFO] Error assembling JAR
>
> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
> does not exist.
>
>
> Any idea?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/10/2013 18:46, Benedikt Ritter a écrit :
> What are the problems and how can we make releasing easier?
I have a real example with JCI. I get an error when running the release
profile with "mvn package -DskipTests -Prelease" :
[INFO] ----------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ----------------------------------------------------
[INFO] Error assembling JAR
Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
does not exist.
Any idea?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Oct 13, 2013 at 7:09 PM, Ted Dunning <te...@gmail.com> wrote:
> On Mon, Oct 14, 2013 at 2:55 AM, Henri Yandell <fl...@gmail.com> wrote:
>
> > I propose release votes be simple revision based requests and involve no
> > artifact churn :)
> >
>
> Hen,
>
> This is a pretty good idea.
>
> But I still think that artifact churn will be a necessary process in order
> to get enough valid QA on the artifacts. But it should be possible to get
> a source artifact out without so much pain.
>
It's up to the those voting I think. ie) they do the churn, not someone
central.
I say: "Lang 3.2 is ready"
You decide your bar is to make sure the changelog looks good (thus checking
the changelog is up to date) and you raise objections over some quick hack
I snuck in.
Phil's bar is that the source must build, tests are good and that the clirr
report ensures backwards compat. So he runs the clirr report and the
general build, then deep dives into the tests and uses cobertura to let him
decide if our quality is regressing.
This continues through others and we reach a consensus after some tweaks
that trunk is ready and now called 3.2 and is ready for packaging. I think
it's important than when people vote, they indicate their steps. That way
the release manager can tell whether or not a vote is deep or shallow.
What this stops us talking about is the announcement email, the website,
the packaging, whether somebody did gpg right or put it in the right place
in Maven and so on ad infinitum. It also stops all of those having to be
the same person - which I think is huge. And it stops us prepping those
every time to have what is hopefully a vote about the code. Which is huge
squared.
The release is when we tag the code - then the release manager has a list
of other things that need to be done and can be asking for help on those
instead of having to learn each item. That allows people to specialize in
those areas and improve them as they (the subgroup) see fit. There are
negatives - the packaging may find a problem in the original source. The
tag for 3.2 may have the wrong maven id and we'll have to decide how we
want to handle it (ie: 3.2.1 or heretical editing of a tag). We may have
releases that don't get all the bells and whistles placing them in whatever
location. The only issues that should show up in the packaging are issues
related to the packaging - it shouldn't, in theory, affect anything
important about the code itself. Suffice to say - I think those 'bugs' are
worth the efficiency.
Hmmm - I've gone from off hand remark while juggling children to serious
opinion :)
Hen
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Oct 14, 2013 at 2:55 AM, Henri Yandell <fl...@gmail.com> wrote:
> I propose release votes be simple revision based requests and involve no
> artifact churn :)
>
Hen,
This is a pretty good idea.
But I still think that artifact churn will be a necessary process in order
to get enough valid QA on the artifacts. But it should be possible to get
a source artifact out without so much pain.
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 14/10/2013 07:45, Henri Yandell a écrit :
> On Sun, Oct 13, 2013 at 9:12 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>>
>>
>> Could be I am misunderstanding the proposal. Do you mean a) RM is
>> not obligated to do anything but tag a release and create tarballs
>> or b) RM should just be trusted to "do the right thing" in getting
>> stuff published and other other PMC members should review / help
>> with "post-release" stuff ad hoc? Could be b) could work as long as
>> we collectively agree to keep an eye on things / review stuff
>> outside of RC votes.
>>
>
> Officially, b).
>
> But, I do think a) is a very interesting stance.
Sorry, I don't agree.
I think that we at Apache have also deep concerns about being sure what
is published really *is* what is on svn. Many people rely on us doing
the right thing.
We have all seen release candidate where some files are missing. Of
course this would not happen with a more automated and streamlined
process, but this is only tehcnical.
In todays world, we also have to remain clear about pressure that could
be done on people to force them to subrepticely introduce or remove
something in published code that is used throughout the world and that
does not publickly appear in SVN. OF course, this could also be spotted
afterwards and the people will immediately lose their karma.
I am a bit paranoid, I know, but I think voting on *signed* packages and
with a consisten web of trust accross our GPG keys is a very important
part of the release process.
So the tag in source code revision system is a start point, it is not
the whole process. Having the community "keep an eye on things / review
stuff outside of RC votes" is really not sufficient for me.
best regards,
Luc
>
> Let's say I think Lang 3.2 is ready and call a vote. Currently the
> community is going to vote -1 simply because I'm not interested in doing
> lots of bells and whistles.
>
> However,
>
> svn tag LANG_3.2 <url>
>
> We're done. Release is done and the only step potentially missing is svn
> export, tar cf, put in a web directory for download. Now those who care
> about having a source tarball in some special place (it's not in svn
> somewhere right?) and all the other things can go do them. I know I've sat
> and kept JIRA's updated for projects who weren't doing so, why is a maven
> repo or whatever else any different?
>
> I'm being extreme, but I think it's an interesting challenge for our
> 'everyone must meet this bar' approach. The more we raise the bar, the more
> star systems slip through our fingers. Erm. Something like that :)
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Oct 13, 2013 at 9:12 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>
> Could be I am misunderstanding the proposal. Do you mean a) RM is
> not obligated to do anything but tag a release and create tarballs
> or b) RM should just be trusted to "do the right thing" in getting
> stuff published and other other PMC members should review / help
> with "post-release" stuff ad hoc? Could be b) could work as long as
> we collectively agree to keep an eye on things / review stuff
> outside of RC votes.
>
Officially, b).
But, I do think a) is a very interesting stance.
Let's say I think Lang 3.2 is ready and call a vote. Currently the
community is going to vote -1 simply because I'm not interested in doing
lots of bells and whistles.
However,
svn tag LANG_3.2 <url>
We're done. Release is done and the only step potentially missing is svn
export, tar cf, put in a web directory for download. Now those who care
about having a source tarball in some special place (it's not in svn
somewhere right?) and all the other things can go do them. I know I've sat
and kept JIRA's updated for projects who weren't doing so, why is a maven
repo or whatever else any different?
I'm being extreme, but I think it's an interesting challenge for our
'everyone must meet this bar' approach. The more we raise the bar, the more
star systems slip through our fingers. Erm. Something like that :)
Hen
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Phil Steitz <ph...@gmail.com>.
On 10/13/13 6:55 PM, Henri Yandell wrote:
> On Tuesday, October 8, 2013, Benedikt Ritter wrote:
>
>> Hi,
>>
>> one of the points that seem to always come up once in a while is the
>> process of releasing components. I've never done it myself so I'm asking
>> people who have done it:
>
> I find myself wondering why a release vote is anything more than:
>
> "I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
>
> That might focus us on the #1 step of whether the API and code is good and
> relegate all the artifact juggling to a post release step. The tag (or src
> tarball of the scm dir) is the important thing - the rest is artifact
> pain/noise and could be handled by different people.
>
> As it is we have a long laundry list of steps to master and get by the 3 or
> 4 RC fails before a release is done. And the list is always changing. Too
> much expertise is needed. It also makes us Maven specific, which may limit
> us if we think broader in the future. We' turn down a JavaScript component
> because I doesn't fit in with out release process.
>
> I propose release votes be simple revision based requests and involve no
> artifact churn :)
I like this idea in principal, but I am not sure that it is
practical, at least until we get a really functional release
packaging and deployment process in place. I have always thought
that what we actually release is source code. There I am with you.
The problem is that we need another way to ensure appropriate
oversight for "publication" of artifacts to make sure that anything
that can be construed as coming from the Commons PMC has the
appropriate contents and nothing else. Our painful gauntlet of RC
preparation now more or less ensures that. If you are proposing
that we stop officially pushing stuff to maven central, for example,
that is an interesting proposition but one that would probably hurt
us community-wise. If we do continue to push stuff there, we need
oversight, so this proposal just ends up postponing the trauma to
post-release and introducing some latency.
On the other hand, once we get to the point where we can "trust our
tools" so that the path from good tag to good artifacts is fully
automated, this will work. Unfortunately, we are just not there
yet. And when we *do* get there, this will all be moot ;)
Could be I am misunderstanding the proposal. Do you mean a) RM is
not obligated to do anything but tag a release and create tarballs
or b) RM should just be trusted to "do the right thing" in getting
stuff published and other other PMC members should review / help
with "post-release" stuff ad hoc? Could be b) could work as long as
we collectively agree to keep an eye on things / review stuff
outside of RC votes.
Phil
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Mark Thomas <ma...@apache.org>.
On 14/10/2013 09:41, Henri Yandell wrote:
> On Mon, Oct 14, 2013 at 12:16 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 14/10/2013 02:55, Henri Yandell wrote:
>>> On Tuesday, October 8, 2013, Benedikt Ritter wrote:
>>>
>>>> Hi,
>>>>
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>>
>>>
>>> I find myself wondering why a release vote is anything more than:
>>>
>>> "I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
>>>
>>> That might focus us on the #1 step of whether the API and code is good
>> and
>>> relegate all the artifact juggling to a post release step. The tag (or
>> src
>>> tarball of the scm dir) is the important thing - the rest is artifact
>>> pain/noise and could be handled by different people.
>>>
>>> As it is we have a long laundry list of steps to master and get by the 3
>> or
>>> 4 RC fails before a release is done. And the list is always changing. Too
>>> much expertise is needed. It also makes us Maven specific, which may
>> limit
>>> us if we think broader in the future. We' turn down a JavaScript
>> component
>>> because I doesn't fit in with out release process.
>>>
>>> I propose release votes be simple revision based requests and involve no
>>> artifact churn :)
>>
>> No can do. ASF policy requires that release votes are on source
>> releases, not svn tags or revision numbers.
>>
>
> A semantic difference.
But an important one.
> Note that our votes in Commons require that we
> identify the svn tag/url and revision the source tarball came from already
> - ie) the source release isn't trusted unless we show where it came from
> [assuming that's still done]. So in reality the vote is on an svn tag and
> revision number, not a source release.
>
> To meet policy, all I need is: "I propose a vote on r5434 of <url>. Here is
> a source tarball I made in 2 minutes of svn export and tar. "
And that would be fine.
> And to curtail the next likely objection, I can also pgp sign that tarball
> if it's required so you know it's from me (not that it's required that my
> pgp be in the web of trust).
That objection wouldn't arise until you tried to publish the release. At
that point the signature is required and no it doesn't have to be in the
web of trust (although there are advantages if it is).
Your public key does need to be in the KEYS file for the project.
> You were happy with me committing to SVN, why
> we need a second set of credentials is beyond me (ie: the ASF itself should
> sign things, I sign when I type my SVN password).
An ASF wide signing service has been discussed a number of times but it
is non-trivial to do so securely. To date, no-one has had the time and
inclination to move the various proposals forward to a conclusion.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Henri Yandell <fl...@gmail.com>.
On Mon, Oct 14, 2013 at 12:16 AM, Mark Thomas <ma...@apache.org> wrote:
> On 14/10/2013 02:55, Henri Yandell wrote:
> > On Tuesday, October 8, 2013, Benedikt Ritter wrote:
> >
> >> Hi,
> >>
> >> one of the points that seem to always come up once in a while is the
> >> process of releasing components. I've never done it myself so I'm asking
> >> people who have done it:
> >
> >
> > I find myself wondering why a release vote is anything more than:
> >
> > "I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
> >
> > That might focus us on the #1 step of whether the API and code is good
> and
> > relegate all the artifact juggling to a post release step. The tag (or
> src
> > tarball of the scm dir) is the important thing - the rest is artifact
> > pain/noise and could be handled by different people.
> >
> > As it is we have a long laundry list of steps to master and get by the 3
> or
> > 4 RC fails before a release is done. And the list is always changing. Too
> > much expertise is needed. It also makes us Maven specific, which may
> limit
> > us if we think broader in the future. We' turn down a JavaScript
> component
> > because I doesn't fit in with out release process.
> >
> > I propose release votes be simple revision based requests and involve no
> > artifact churn :)
>
> No can do. ASF policy requires that release votes are on source
> releases, not svn tags or revision numbers.
>
A semantic difference. Note that our votes in Commons require that we
identify the svn tag/url and revision the source tarball came from already
- ie) the source release isn't trusted unless we show where it came from
[assuming that's still done]. So in reality the vote is on an svn tag and
revision number, not a source release.
To meet policy, all I need is: "I propose a vote on r5434 of <url>. Here is
a source tarball I made in 2 minutes of svn export and tar. "
And to curtail the next likely objection, I can also pgp sign that tarball
if it's required so you know it's from me (not that it's required that my
pgp be in the web of trust). You were happy with me committing to SVN, why
we need a second set of credentials is beyond me (ie: the ASF itself should
sign things, I sign when I type my SVN password).
Hen
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Mark Thomas <ma...@apache.org>.
On 14/10/2013 02:55, Henri Yandell wrote:
> On Tuesday, October 8, 2013, Benedikt Ritter wrote:
>
>> Hi,
>>
>> one of the points that seem to always come up once in a while is the
>> process of releasing components. I've never done it myself so I'm asking
>> people who have done it:
>
>
> I find myself wondering why a release vote is anything more than:
>
> "I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
>
> That might focus us on the #1 step of whether the API and code is good and
> relegate all the artifact juggling to a post release step. The tag (or src
> tarball of the scm dir) is the important thing - the rest is artifact
> pain/noise and could be handled by different people.
>
> As it is we have a long laundry list of steps to master and get by the 3 or
> 4 RC fails before a release is done. And the list is always changing. Too
> much expertise is needed. It also makes us Maven specific, which may limit
> us if we think broader in the future. We' turn down a JavaScript component
> because I doesn't fit in with out release process.
>
> I propose release votes be simple revision based requests and involve no
> artifact churn :)
No can do. ASF policy requires that release votes are on source
releases, not svn tags or revision numbers.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to
make it easier?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 14/10/2013 03:55, Henri Yandell a écrit :
> I find myself wondering why a release vote is anything more than:
>
> "I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
+1, assuming the revision has almost everything ready for a release (at
least up to date release notes).
That may also encourage people to review more the functional aspects of
the release (e.g. are the new features properly tested? Does the API
look right?) than commenting on the PMD/Checkstyle reports.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make
it easier?
Posted by Henri Yandell <fl...@gmail.com>.
On Tuesday, October 8, 2013, Benedikt Ritter wrote:
> Hi,
>
> one of the points that seem to always come up once in a while is the
> process of releasing components. I've never done it myself so I'm asking
> people who have done it:
I find myself wondering why a release vote is anything more than:
"I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
That might focus us on the #1 step of whether the API and code is good and
relegate all the artifact juggling to a post release step. The tag (or src
tarball of the scm dir) is the important thing - the rest is artifact
pain/noise and could be handled by different people.
As it is we have a long laundry list of steps to master and get by the 3 or
4 RC fails before a release is done. And the list is always changing. Too
much expertise is needed. It also makes us Maven specific, which may limit
us if we think broader in the future. We' turn down a JavaScript component
because I doesn't fit in with out release process.
I propose release votes be simple revision based requests and involve no
artifact churn :)
Hen