-----Original Message----- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 7:09 PM To: Commons HttpClient Project Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Kalnichevski, Oleg wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
