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).
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).
For VelocityTools, i have more plans/ideas than i care to list. :)
Many have half-baked code already written out.
- Are external velocity projects currently actually interested in a move to
apache ? (don't if that
is an argument though, since the Umbrella type projects is currently not really
high on the boards
wishlist, if I understand correctly)
Click has shown interest in moving over. Regarding the umbrella
issue, i have two responses: a) Velocity is already both an umbrella
and in an umbrella. This would at the very least be a step in the
right direction b) In my opinion, the fatal mistake of most
"umbrellas" is having shared interest that is only conceptual and no
"center pole". For an "umbrella" to work, there must be shared
investment and concern in a single central codebase. So long as the
member projects are tethered together in that manner, i think the
benefits of knitting otherwise disparate communities into one will
outweigh the problems. Of course, i see trade-offs either way..
- 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.
- 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.
- You just got a lot of potential new committers, with opening up jakarta svn
access. Did that spark
any new interest ?
Not that i can see or foresee at this point.
Just a few thoughts to consider with a proposal :)
Thanks! Please keep it coming. The more feedback aired, the more
confidence we can have in making the decision.
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]
