On 22 June 2013 19:42, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > Am 22.06.2013 19:10, schrieb Gary Gregory: > >> On Jun 22, 2013, at 12:41, Phil Steitz <phil.ste...@gmail.com> wrote: >> >>> On 6/22/13 7:26 AM, Mark Thomas wrote: >>>> >>>> On 22/06/2013 14:45, Gary Gregory wrote: >>>>> >>>>> I'm for whatever does the RM process easier and less error prone. If >>>>> that means maven plugins, so be it. >>>> >>>> This is written as someone who has never released a commons component >>>> and is very grateful for the folks that have done the release work for >>>> the components he has been involved in. >>>> >>>> I see various messages indicating how hard / complex / tricky / easy to >>>> get wrong doing a release is. The frequency of the messages does not >>>> appear to have changed significantly over time and they have been sent >>>> but both newcomers to the project and folks that were here long before I >>>> was. >>>> >>>> I can't help but think that we must be doing something wrong. The Tomcat >>>> release process is a breeze. It takes me about 2 minutes actual work. It >>>> takes longer to upload the release artifacts for voting. And I spend >>>> even longer making sure I am happy with what I am about to tag. >>>> >>>> The obvious difference is that Tomcat is primarily an Ant based release >>>> process with a little bit of Maven to talk to Nexus whereas the Commons >>>> releases are primarily (wholly?) Maven based. However, I can't believe >>>> that this is a tools issue. If everyone found Maven this hard to release >>>> software with, no-one would be using it and it is clearly popular. That >>>> begs the question: what are we doing wrong? Why do releases appear to be >>>> much more difficult than they should be? >>>> >>>> I don't have answers neither do I have the Maven knowledge I suspect is >>>> necessary to figure the answers out. I encourage those that do have the >>>> Maven skills to put on their thinking caps. >>> >>> >>> +1 >>> >>> I think that is what sebb and others have been doing working on >>> build plugins. Lets agree on a simple way to make these plugins >>> available, get them really working, document their use and then >>> enjoy the stability :) >>> >>> So in the spirit of removing barriers, I would like to propose the >>> following: >>> >>> 0) We designate a new class of commons components, called "commons >>> RM" or "commons-plugins." These things do not have web sites and >>> are not otherwise advertised or promoted for use outside of >>> Commons. Their sole purpose is to help Commons release managers >>> prepare and manipulate release candidates. Their use should *not* >>> be required to execute the basic maven goals involved with building >>> the software - i.e., "mvn jar" and "mvn install" should work without >>> them. In other words, users should be able to build from source >>> tags without them. >>> >>> 1) [RM] components can be released at any time via lazy consensus >>> VOTE, as we do now for commons parent. >>> >>> 2) RMs agree to collectively maintain these components and update >>> /releases so that the directions there work with currently released >>> versions of the [RM] plugins. >>> >>> To get to windows of stability for the components I have released, I >>> have always resorted to custom bash scripts, which have worked fine >>> for me, but I understand a) not all RMs run unix b) we should be >>> trying to limit the things requiring shell access and c) >>> uncoordinated per-component scripts tend to break. The advantage of >>> sebb's approach is that (like what the Tomcat Ant scripts do) it >>> eliminates the need for command-line scripting to create and manage >>> RCs. With all of the maven expertise we have here, we should be >>> able to get something working that meets the needs of at least most >>> active Commons components. Lets not get tied up in release >>> mechanics for the tools to make releases easier :) >> >> >> +1. We can propose to graduate the plugins to Maven later when we have >> them good and working for our use cases. > > > +1 from me, too. This seems to be a good approach. > > Coming back to sebb's original proposal to access the plug-ins from a local > maven repository: Would it be possible to integrate them (and our whole > release process) into a CI environment? For instance, there could be Jenkins > jobs that build and deploy an RC so that it is ready for a vote. Then RMs > don't have do any local setup.
That's a separate issue entirely; please start a new thread. > Oliver > > >> >> Gary >>> >>> >>> Phil >>>> >>>> >>>> Mark >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
