Adam, We will be more than happy to play by the rules, as long as they are clearly articulated and agreed upon, not just imposed upon us. There is one thing I really have an issue with: why do we have to have separate CVS modules per version under development, where a more natural way for me (very GUMP illiterate person) is to have a CVS branch per version being developed. It may happen that we will end up having yet another development stream in addition to version 2.0 and 2.1 development. Would that require yet another CVS module to remain GUMP friendly?
Nobody said that you need a cvs module per development branch (and I have no idea where you'd get that from...). Gump lets you specify CVS branches/tags, it's just that many "Gump folks" see such requests as a sign of something else going wrong (for example, projects not playing nicely with the others). That being said, it would probably make sense to set up a commons-httpclient-2.0 project in gump, which would be based on the maintenance branch.
-chris
(The name "Gump" is not an abbreviation BTW)
Or am I just missing something? Please advise.
Oleg
-----Original Message----- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 6:30 PM To: Commons HttpClient Project Cc: [EMAIL PROTECTED] Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Oleg wrote:
Adam, with all due respect let me point out that we have stable HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API and/or code stability. If GUMP cannot be configured to use any other CVS
branch but
HEAD, this is a totally different kind of a problem, and it should be
brought up to GUMP
folks, not to us.
Gump can be configured, but it is community configured, and your project has selected this configuration.
I am (very recently) a "gump folk", although still learning -- and these opionions are most definately, my own -- however I think we are discussing "Gump ettiquette". I think your project unwittingly did something a bit unfriendly, and I'd like to cultivate a "gump how-to" or "how-to-be-a-friend-of-gump" that helps you/other projects from doing the same in the future.
I care because I feel Gump supports inter-community respect, and project collaboration, and I want projects to depend upon each other more, not less.
Gump's philosophy is to use CVS HEAD, and does so by default. You could've set your project to use the stable tag, but without it you involved all your dependees in any major changes. Now debatably this is a good thing, it helps you find the problems, but as your list of dependees gets long (and I hope it does :-) and if things fail, then this stops a whole sub-tree of Gump from Gumping ... and hence is detrimental to the community. As such, a separate transition project (one for stable, one for CVS HEAD) allows you and sub-projects to decide when to "test the new stuff" and you (via aliasing) can decide "when to flip the switch".
As for having unit tests run in the gump project, there are three schools of thought. First says don't do them, Gump is for compiling -- unit tests cost Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them to your main project. Third says -- create a separate xxx-test project for your unit tests. The logic behind the third (which I am becoming a fan of) is that dependees can then chose to depend upon xxx or also upon xxx-test. Typically unit tests are very strict, so depending upon xxx-test might cause wasted gumping (a compile error might not be found due to some obscure unit test failing), so folks would normally not depend upon xxx-test (their yyy-test would find it) unless they felt xxx was unstable, and then they could.
I think these are nuance of using Gump that escapes most Gump project configurer [I am just getting them], and I think it needs to be address via some sort of "FriendOfGump" guidelines documentation on Gump. I am copying the Gump list for their input, and if a conscensus is there I'll try to write up the documentaton.
regards
Adam
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
