On 8/23/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:
On 8/22/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> I'm +1 to Velocity going TLP :)
reallly? no way! ;-)
:)
> I'm not concerned with the dormancy worries. The board have processes
> in place for telling when something has gone inactive (they fail to
> report), whereas Jakarta doesn't. So I'd much rather it be
> velocity.apache.org that goes into dormancy than
> jakarta.apache.org/velocity.
I'm with Geir. What does dormancy have to do with it? Dormancy is
the opposite of our plans.
Martin brought it up as a worry for Velocity moving to TLP.
"My main concern here is that when no external projects join, will the
project move into dormant state ?"
So my view is that I'd rather see a dormant velocity.apache, than a
dormant jakarta-velocity - if I had to see one of the two that is.
> Slide to TLP hasn't been much of a success - but it took that lack of
> success for us at Jakarta to notice how inactive they were.
>
> Some thoughts with my crazy-ideas hat on:
>
> * Remain on one mailing list. Even if .Net versions come in etc, keep
> tight to one community and not subcommunities.
i agree much good can come of keeping one list, but i think there
needs to be some ability to opt out of some parts like issues or
commits.
Yeah, definitely. To answer your later email, I mean dev list.
> * Keep using the Jakarta SVN permissions rather than making new ones.
> ie) all of Jakarta can still commit to Velocity (and vice versa).
-1 if we're separating, let's separate. Besides, the flattening of
jakarta svn permissions has had zero impact on velocity to this point.
If any jakarta committers that got permissions in the change wish to
maintain them, we should give them that opportunity, but let's not
bring them along by default and especially not immediately let new
jakarta committers be new velocity committers.
Ah well, had to try :)
> * Don't feel obliged to make your chair be whomever is the current
> brains behind Velocity. Much healthier for the chair to not be the
> main driver code-wise.
To followup the second part of this for Geir's reply. My claim is that
it's healthier for the chair to not be the main driver, because then
you end up with two active individuals being responsible and you don't
end up in a benevolent dictator model.
> * Do the TLP vote and board approval before the next release; however
> time the TLP changes (website for example) to coincide with the
> release and talk to the PRC about capitalizing on that.
Sounds like a nice goal and all, but i'm more concerned that these
things happen when they're ready, regardless of relative timing. i
don't see that much benefit in exerting great effort to coincide the
two. if it's easy or if it just happens, then great. if not, no big
deal to me.
Fair enough. As I said, mad ideas. This seemed like a good idea
marketing wise, but I'm clueless as to whether it would have enough
value to be worth the effort.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
