Yeah, but he could be a velocity committer w/o click being in the TLP. Click sounds like a good candidate for a project on it's own.
geir Will Glass-Husain wrote: > By the way, Click is an interesting case study for eventual TLP inclusion. > > Click is an innovative approach to web frameworks with an active > community. The lead developer (Malcolm Edgar) has been actively > participating on the velocity lists and supplying patches. > > There's a good cross-fertilization of interests. Malcolm's been a big > advocate for more useful error-reporting in Velocity (particularly > when integrating with other frameworks). Many of his patches and > comments have been related to these issues. He's also brought to our > attention compatibility issues with Cayenne. > > The fact that Malcom's been energized around the error-reporting and > integration issues has been good for our project. More projects in > the TLP will lead to more diversity in the developers. It's a little > dangerous if all the committers use Velocity in essentially the same > way. > > WILL > > On 9/24/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: >> On 9/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> > Nathan Bubna wrote: >> > > On 9/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> > >> Nathan Bubna wrote: >> > >> > On 9/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> > > <snip> >> > >> >> I'm +1 and -1. >> > >> >> >> > >> >> I'm +1 as I do think that Velocity as a TLP is not >> unreasonable. Not >> > >> >> necessary, but not unreasonable. >> > >> >> >> > >> >> I'm -1 because I'm worried that this is a new kind of umbrella >> that's >> > >> >> planned. Making it a catchall for things that are and use >> Velocity is >> > >> >> going the wrong direction. >> > >> > >> > >> > Nothing new about it. Velocity became just such an umbrella under >> > >> > your leading, or am i mistaken about your part in forming DVSL and >> > >> > VelocityTools? :) >> > >> >> > >> Tools was created because we wanted to offer support for struts >> users, >> > >> and struts didn't want it. We didn't create a replacement for >> struts. >> > >> And yeah, it grew in scope. >> > >> >> > >> DVSL was similar. Maybe it could have gone into commons, but >> again, it >> > >> was home grown. >> > >> >> > >> And "Billy did it too!" isn't really a good reason to do it :) >> > > >> > > Agreed. And neither do i think "Johnny couldn't do it" is really a >> > > good reason not too do it. :) >> > >> > I don't understand that argument. You are trying to say "no, we're not >> > an umbrella" while saying "yes, we are, but you did it too". I'm >> having >> > trouble resolving these two confusing messages. >> >> I wrote a fairly long post on velocity-dev some weeks back in response >> to Martin vdb's concerns (which were similar to yours) that addressed >> this confusion. I'll try to summarize briefly... >> >> I don't think the word "umbrella" fits Jakarta. Jakarta is more of a >> tarp or at best a canopy of sorts. It's a sack full of projects with >> no center. But because the word "umbrella" has been attached to >> Jakarta (and Logging and Db and Xml), all of their problems (and few >> of their successes) are now unfortunately associated with it around >> here. >> >> Velocity, on the other hand, has already been what is in my mind a >> functional and successful "umbrella". It has a center pole around >> which its the sub-projects have and will continue to revolve. >> >> So, to point: i'm torn between trying to redefine "umbrella" or just >> eschew the word altogether due to its illegitimate (IMHO) baggage. >> >> But more specific to the conversation above, i was simply rebutting >> your argument that Velocity being an umbrella is something new. My >> statement that it was under your leading was tangential. I'm not >> pushing this move to TLP on the merits of what other projects or even >> Velocity in the past have done or have failed to do well. And rather >> than take the time to repeat the reasons, i'll just refer you to my >> past posts on the subject. >> >> > >> > And the idea is not that all Velocity using projects are >> welcome, but >> > >> > that we are free to invite projects that are explicitly built >> upon or >> > >> > for Velocity. There are big differences between being free to >> invite >> > >> > projects and being a "catchall" and between being a project >> that uses >> > >> > or supports Velocity and one that is explicitly built for or upon >> > >> > Velocity. >> > >> >> > >> How do you draw the line? >> > > >> > > That's the real question here. I'd love to hear good thoughts and >> > > suggestions on this. I wrote/modified the proposal as well as i >> > > could, but i would very much appreciate more specific feedback on the >> > > wording of the charter-ish stuff in there. Of course, i'm probably >> > > explaining my thoughts on this question more clearly in these >> > > discussions than i did in that document... So, to summarize, the >> > > "line" should be drawn: >> > > >> > > - On a case by case basis. >> > > - Carefully by the participating members of the Velocity PMC >> > > - To the exclusion of projects which simply use or support Velocity, >> > > without being explicitly and primarily built for use with the >> Velocity >> > > template engine and/or firmly upon the core Velocity codebase. >> > >> > Sure - there could be a rule that "it only works with velocity" - IOW, >> > w/o velocity, it doesn't function. >> >> Yeah, that sounds like a great way to simplify this criterion! >> >> > Velosurf seems to be a good example of this. >> > >> > > - To the exclusion of projects whose developer communities have no >> > > lasting interest and investment in the health and development of the >> > > core Velocity codebase. >> > >> > That's hard to measure. If that's known as a criterion, people will >> > just say the right things. >> >> True. Let me try a rephrase of it: >> >> - To the exclusion of projects whose developer communities have not >> demonstrated consistent interest and investment in the continuing >> maintenance and development of the core Velocity codebase. >> >> To me that calls for some evidence like bug reports, patches, >> participation on dev@, etc. >> >> > > How's that sound? >> > > >> > >> >> If there are projects that aren't template engines that want to >> > >> come to >> > >> >> Apache, the door is open and they are welcome. >> > >> > >> > >> > And template engines are welcome too, right? The question is >> whether >> > >> > being here would be just about them having the foundation and >> > >> > infrastructure support or if there is a community aspect too. If >> > >> > community matters, then it matters where they fit in Apache >> > >> > organizationally. So rather than a blanket statement that any >> > >> > Velocity-related projects are welcome or not welcome, i prefer >> having >> > >> > the freedom to individually vet the merits and fit of project >> > >> > interested in joining the Velocity TLP. And you, as a Velocity >> PMC >> > >> > member, would be very, very welcome to join in those >> discussions and >> > >> > decisions. >> > >> >> > >> Sure - I think thought that the project charter should be clearer. >> > > >> > > I would love it to be. Please help! >> > > >> > >> >> But putting anything that uses Velocity into a TLP is like using >> > >> things >> > >> >> that use log4j into the same TLP (which would re-create >> Jakarta... :) >> > >> > >> > >> > Yep, good thing that's not the plan! :) >> > >> >> > >> That's not obvious to me. >> > > >> > > Hopefully you mean that "wasn't" obvious to you. I've gone to some >> > > pains to explain this... :) >> > >> > I'm slow. >> >> funny, and here i thought you were just busy... is Harmony not taking >> much time anymore? ;) >> >> --------------------------------------------------------------------- >> 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]
