I'm +1 to Velocity going TLP :)

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.

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.
* Keep using the Jakarta SVN permissions rather than making new ones.
ie) all of Jakarta can still commit to Velocity (and vice versa).
* 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.
* 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.

Hen

On 8/19/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
And it was only 8 months ago that Jakarta suggested that Velocity go TLP.  :-)

http://mail-archives.apache.org/mod_mbox/jakarta-velocity-dev/200601.mbox/[EMAIL
 PROTECTED]


On 8/19/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>
>
> Nathan Bubna wrote:
> > On 8/16/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> >> First of all, I am not opposed to a move to TLP.
> >>
> >> Malcolm Edgar wrote:
> >> > I think the TLP will be a good move for Velocity, raising its profile
> >> > and getting its development moving again. So for what its worth +1
> >> > from me.
> >>
> >> "It will get better when..." doesn't work very well is my experience.
> >> If development isn't moving,
> >> it isn't going to move very fast either when TLP. It will raise the
> >> profile a bit, but I think a
> >> release is really raising the profile and at least will give you some
> >> idea how things will be when
> >> there is some new press around velocity. Will it indeed attract new
> >> people ?
> >
> > Perhaps, who knows?  But with this proposal, i am more hopeful of
> > getting more help from those like Malcolm who around and invested in
> > Velocity but have not yet contributed much, by bringing them on board
> > (either directly or with their projects) and getting them access (i.e.
> > increasing ownership and convenience).
> >
>
> No one is currently holding back on him getting involved. TLP status doesn't 
still needs him to earn
> the right to get committer access to velocity and depending on the security 
model you choose, when
> the project gets out of the incubator, it will still not be sure he is a 
committer of the main
> codebase. So he could be starting now and join Velocity on the road the 
tomorrow :)
>
> >> For a proposal like this to succeed, the proposal is I think lacking
> >> some important information :
> >>
> >> - Are there any concrete plans for the future direction for Velocity ?
> >
> > 
http://issues.apache.org/jira/browse/VELOCITY?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> >
> >
> > Key future things on my radar are whitespace handling (though we have
> > no concrete plans there as yet), ditching many checked exceptions,
> > security improvements for those with third-party template authors, and
> > JDK5 stuff (esp. Generics and Iterable).
>
> The whitespace handling is something that needs some work indeed ;)
> I like clean output :)
>
> >
> > For VelocityTools, i have more plans/ideas than i care to list. :)
> > Many have half-baked code already written out.
> >
> >> - Since Velocity is considered mature, what is going to happen if
> >> Velocity is going to live on it's
> >> own, if in the end no projects decide to come to the velocity project ?
> >
> > i can safely say that VelocityTools will come :).  And i doubt anyone
> > will protest about us dragging DVSL along as well.  Even if Click or
> > Velosurf or any others we'd like to invite decide not to join us, i
> > think these three projects nonetheless should stay together and find a
> > better home than Jakarta.
> >
> > But, excepting VelocityTools and DVSL, i would say that Velocity would
> > be little more or less alone as a TLP than it is in Jakarta these
> > days.  So should your scenario play out, i see no real loss.
>
> I was explicitely talking about projects not deciding to come to velocity. 
Afaik velocitytools and
> dvsl are already at velocity :)
> My main concern here is that when no external projects join, will the project 
move into dormant state ?
> And also when projects would like to join velocity, how are you going to 
handle the project in the
> incubator (luckily velocity has enough members, but those members are also 
pretty busy) ?
>
> >
> >> - What problems is Jakarta giving you ? The current reasons described
> >> aren't really good reasons,
> >> since (afaik) you never ran into any issues (no one is holding you
> >> back to release, no requests were
> >> being made to add an external velocity project through the incubator)
> >
> > True, i wouldn't say Jakarta has given us problems.  I do think,
> > however, that Jakarta in general has problems (c.f. umbrella
> > discussions), and that both Jakarta and the Velocity projects may be
> > helped in their parting.
>
> Agreed. As I said at the start of the previous e-mail I am absolutely not 
opposed to velocity going
> TLP. Just want to make sure everything (or at least as much as possible) is 
covered, so the board
> has all the information to base their decision on.
>
> Mvgr,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to