Henri Yandell wrote: > 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.
Why are we talking about dormancy? > > 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). -1 If it's going to be a TLP, let it be a TLP. > * 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. I agree with the first sentence as to not being obligated, but the second is somewhat unproven as "much healthier". It think it can be just as successful either way. > * 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
