commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging Plugin - move to proper from sandbox)
Date Sun, 23 Jun 2013 12:56:39 GMT
On 22 June 2013 17: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:
<snip>

>>
>> 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

> 1) [RM] components can be released at any time via lazy consensus
> VOTE, as we do now for commons parent.

+1

> 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.

+1

> 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

But we still need to resolve:
- where in SVN these tools belong
- how to ensure the tools are readily available to RMs

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


Mime
View raw message