> I totally agreed Peter. But for the developers, if they are simply too busy, there >is nothing we can do about.
I really don't think so since it isn't working that way... We learned the "hard way"... :) > Maybe we can take a different approach here. Fix up things that are *critical* and >then release (I'm interested in a > velocity tools project beta release and it is sooo... close except a couple of >issues). For things that can be done but > not already a function of velocity, leave it for the next release (ie numerics, >etc...). I am trying to push the development of a "next release". :-) I would not write such a mail if my only intention was "Oh please, implement that single special super-feature I really need!" or "I am upset that you did not touch my proposal." And if I can trust my sences I don't think that many people won't get what I mean. Not that they could if they want :) > I really think that Velocity is super nice and elegance as is right now. If we need >to substantially improve it, there > might be lots of re-desiging work not to mention keeping backward compatibility. I think there is a need for improvement. It is working for me at the moment, but there are some weird things and things to be added. There are enough features / bug fixes that could be added without the need of big re-designs (Map-Support, #local (since Geir already put it in :), Number Support ...) And I want to help developing it not only demanding the others to do so! Peter BTW: HTML-Posts are quite hard to quote and it is bad for the archives... -----Original Message----- From: Peter Romianowski [mailto:[EMAIL PROTECTED]] Sent: Sun 12/08/2002 22:15 To: 'Velocity Developers List' Cc: Subject: The most friendly PITA (long) Another week is gone and I start to feel like the PITA of some of the readers. :| I also start to consider the possibility of "fork your own codebase and shut up" (as basicly provided to me on the list some time ago) as a bad but maybe the only choice left :(. I would still like to work on velocity (improving the number support (has anybody tested it already?) or propose a #filter meachanism or help coordinating thins - see later) but I do not see any sence in doing so! I could live with a paradigm that says: "Well, please propose your patch 3 times - we're too busy" as it is on tomcat-dev for instance. But *there's* a living discussion and development going on! And that is *totally* missing here for way too long now! From time to time there are people discussing things - most times without any result. Why isn't there anything like "Vote for #local" or "Vote for number support proposal"? With rules like "X +1 means - go for it" and "any -1 from the core team means: no go - more discussion needed" (As I think that was the main reason Geir dislikes votes). That way we (you) could step out of this "we're talking about things for a while but if the thread's over..."-thing. This list is starting to become some kind of "academical discussion list" (more details later on). A proposal for further development ---------------------------------- So maybe someone could work out something like a "Road Map" with things like: 1. What to do with 1.3.1? 2. What to implement for 1.4? 3. What would come in 2.0? I mean: It's enough there! 1. and 2. can be nearly extracted from the list archives as there were so many discussions and even proposals (Map-Support, Number-Support, #local, Whitespace- stuff (#filter)...) And enough people seem to be interrested and come up with good ideas and even proposals / patches! That could be discussed (every piece of it separately, since the first two things are really "only" feature lists, whereas the third thing could contain something like "rewrite this or that" or "add a total backwards compatibility killer"). The best thing would be to assign a single person to the task of updating the document and bringing it to the discussion again and again until it's time to vote on something. And then we could go into details for every point on each list and discuss implementation details. I would really like to see more "solution driven development" instead of "philisophical discussions". Some things do not need that much discussion (like a #local directive or improving the #macro capabilities (using macros from #parsed files)) IMHO. Or the discussion is over and now it's time for actually doing it (number support?) Don't get me wrong: Discussion is good! But it could be a bit more pragmatical (since Velocity is still a *tool* and not a whole new technology or science - IMO :). Don't get me wrong again: I don't want to leave the "Simplicity-Paradigm" and implement every "please come into my mind"-feature in the core! The above proposal of working on a "Road Map" (really not the right word - found no other) is basicly a thing I wanted to throw in for a long period of time since I think it is really time to move things forward (and thus not only maintaining what's there). Note to JR (who's still reading the list I guess): I *know* what you're thinking! :) And as always: No personal assult. Peter [One sentence: I like Velocity and I *really* want to help to improve it further, but I will *leave* disappointed if we cannot manage to bring back life to it.] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
