The challenge with this discussion is that it is unclear whether it really benefits a project to be TLP'd? I would highly recommend a conservative approach in this sort of decision making, because once you've left jakarta, I suspect you'll get alot of flak if theres a realization afterward that it was a poor decision.

And, while this whole TLP movement is very "empowering", it also has the risk of creating a lot of chaos, disorganization, and could rather promote "anti-standardization" practices. I think the ultimate benefit of Apache is that we're not a bunch of "Cowboy Programmers", but a "Consensus Driven Meritocracy", that results in a inherent level of interoperability and consistency.

I think ultimately you need to consider what your requirements for TLP status are, are your needs really that drastically different from that of other Jakarta or Apache Commons Projects that you require that extreme a level of independence. What is it about being in Jakarta that is a limitation?

I would probably vote -1 on such a move for a HttpClient TLP. Simply because I think we need to keep Java related Apache projects somewhat close together to maintain interoperability and standardized packaging and development practices.

I understand "Gump" is currently working to get TLP status. Alot of the arguments there seem to make more sense to me, Gump needs its independence from jakarta to get interoperable with many other TLP and projects external to Apache and is being implemented in multiple languages. Gump needs that TLP status to get a foothold and become the standard approach to Integration Testing across platform and language, as such its a strong candidate for a flagship product for Apache.

my humble $0.02,
-Mark

--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to