commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging Plugin - move to proper from sandbox)
Date Sat, 22 Jun 2013 18:42:22 GMT
Am 22.06.2013 19:10, schrieb Gary Gregory:
> On Jun 22, 2013, at 12:41, Phil Steitz <phil.steitz@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.

Oliver

>
> Gary
>>
>> Phil
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> 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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message