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]
