Apologies for writing this as a blog rather than an email - it felt
more natural and will pull in other opinions:
http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
Hen
-
To unsubscribe, e-mail: [E
-- Forwarded message --
From: William A. Rowe, Jr. <[EMAIL PROTECTED]>
If you have only 30 seconds to read this;
Join us in celebrating the ASF's 10th Anniversary at ApacheCon!
The Call for Papers is now open for ApacheCon US 2009, taking place 2-6
November in Oakland, Californi
Henri Yandell a écrit :
> (From the Jelly thread)
>
> With Jelly as an first use case I'd like to propose a process for
> marking a component as inactive. Said process being:
>
> 1) Vote on commons-dev. 7 days minimum (though there's no real rush).
>
> 2) Make inactive:
> a) remove from trunks
trunks-proper = externals *nod* Basically pulling out of our 'active'
development set. The same way that active branches should be in the
trunks-proper.
What does your last line mean?
On Fri, Nov 7, 2008 at 9:52 AM, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
> Henry,
>
> I'm not opposed to such a
Henry,
I'm not opposed to such a process for Jelly.
One important point is that migrating from and to N.A.M. is relatively
flawless.
What does imply "remove from trunks-proper", just an externals?
If yes I would have no big problem.
Please note that making the docu reasonable is a bit more
(From the Jelly thread)
With Jelly as an first use case I'd like to propose a process for
marking a component as inactive. Said process being:
1) Vote on commons-dev. 7 days minimum (though there's no real rush).
2) Make inactive:
a) remove from trunks-proper
b) Update the homepage to say "N
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-configuration-test has an issue affecting its community
integration.
Thi