hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Date Fri, 05 Sep 2003 17:41:41 GMT


-----Original Message-----
From: Christopher Lenz [mailto:cmlenz@gmx.de]
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:ajack@trysybase.com]
> Sent: Friday, September 05, 2003 6:30 PM
> To: Commons HttpClient Project
> Cc: gump@jakarta.apache.org
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message