On 9/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > well, we have the annotation changes needed for geronimo, that were not > allowed in 6.0 > personally, I think that was enough to keep trunk alive. > Let's say that I did have a huge architecture change, lets say, I want > to swap out ByteChunk/CharChunk for ByteBuffer/CharBuffer and also use > nio charset conversion, > then doing that in trunk is not so appropriate either. So I will do that > in sandbox, the right place for an experiment like that. Maybe it turns > out that it worked perfectly, and we want to put that into Tomcat, we > can't put it in 6.0, that would be insane, and we don't have a trunk, so > where do we put it?
For ByteChunk -> NIO - it's clearly an API chnge, so according to the new proposal ( that seems to have a large enough majority and got clarified in many ways - probably can be put to a formal vote ): RTC. If a majority ( at least 3 +1, more +1 than -1 ) think this should be done - we can discuss if this is big enough to move from 6.0 to 6.5 ( I think it is - because will change a lot of APIs ), or if there are way to keep the old API working alongside with a new one ( backward compatibiliy is quite important ). Alternative answer: since the connector interface is heavily using ByteChunk, you may start it as a separate package from coyote ( nio-coyote ? ), add hook points so you can use nio-coyote connectors at the same time with coyote ones. Most of the work can be CTR, in 6.0 ( maybe a 'modules/' directory ). I'm not sure if this is technically feasible due to deps - but if I a vote comes up, I would vote for a proposal that preserves backward compat, and -1 if all existing connectors need to be rewritten. For the others - again, you have the choice to implement them as a plugin, CTR. If it needs API/core changes - those need to be RTC and get majority. IMO if you want it done - minimizing API changes and doing most of the work in a component has bigger chances, but it's your proposal :-) In all cases - it's a simple vote to decide if an API change or core features gets in using RTC rules. And it's also a simple vote to move from 6.0 to 6.5 ( and freeze 6.0 - all new code/changes will go to 6.5 ). Removing trunk, pretty much halted any chances for future innovation, as > approved sandbox experiments have nowhere to go. 6.0 is really the place where active development on tomcat should happen until a 6.5 proposal is passed, so that's the real trunk ( no matter how it's called ). The only issue is that "innovation" that affects API or core should be RTC - i.e. requires more than one person making arbitrary changes ( that may be valid and good - but as with any API change should be more controlled and have more support than a simple 'it works' ) And again - it's a simple vote to go either way, no need to fight or take it personally - every person has a different (and valid) opinion and may want to do things his (better) way, but needs to give up a bit for the sake of the others. Costin
