Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
On Mon, 8 Sep 2003, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > However, most of my statement (and now question) is about > friend-of-gump behaviour, and having that project is good, but not > "friendly" 'cos it forces work onto sub-projects. I'm not sure. > Do you not agree that the project should manage itself, should > create the new (temporarily unstable) codebase as the sub-named > project, and should either alias (via name="commons-httpclient" .. name="commons-httpclient-old-stable-branch" inherit="all") or rename > projects in order to manage it for folk? It would be nice if they did. Many projects consider Gump either a community service maintained by others (most committers don't even know they have commit access to the jakarta-gump module) or a nuisance. I think it is perfectly legitimate for a project to move forward and break backwards compatibility after a deprecation period that's been long enough and included at least one stable release. Whether such a project decides to move forward in CVS HEAD or in a branch is up to its committers. If they manage its Gump descriptor to take the problem into account is a different issue - see above. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Stefan wrote: > > Please note that there already is a commons-httpclient-2.0-branch > project in Gump's workspace. It would be trivial for projects to > depend on that branch instead of CVS HEAD and in fact jakarta-slide > and xml-rpc already do so. > Thanks, I'd not seen that. However, most of my statement (and now question) is about friend-of-gump behaviour, and having that project is good, but not "friendly" 'cos it forces work onto sub-projects. Do you not agree that the project should manage itself, should create the new (temporarily unstable) codebase as the sub-named project, and should either alias (via
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
On Fri, 5 Sep 2003, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > 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. Please note that there already is a commons-httpclient-2.0-branch project in Gump's workspace. It would be trivial for projects to depend on that branch instead of CVS HEAD and in fact jakarta-slide and xml-rpc already do so. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Oleg wrote: > 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. I completely agree, and like I said -- these aren't even "mandatory rules" more "here is how to play nicely w/ other Gumpers". I also agree it is upon the Gump folk to agree and document/communicate these things. I think this has been in the heads of "those in the know" for too long... > 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? Yikes, did I communicate this? No, not at all! I think we have a terminology miscommunication... Upon investigating how I see that one has to have multiple gump module descriptors for separate tags/branches in one CVS module, but that is doable. I beleive you can "alias" (via depends) to set the commons-httpclient to any one of your two (or three) tags. I will find some time to check this all out, and write it up/document it on the gump site. That said, the Jakarta POI recently did this with two module descriptors, but the same effect (although no aliasing): http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi.xml?rev=1.29&content-type=text/vnd.viewcvs-markup se http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi3.xml?rev=1.4&content-type=text/vnd.viewcvs-markup There are (at least) two ways to get a tag/branch for a module (I am still investigating on project). For reference see: http://jakarta.apache.org/gump/module.html w/ the "tag" on module and the "cvs" information. IF you look here I think you'll see a number of such examples: http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/#dirlist As I said, I care about this sort of stuff so am happy to try to help and/or document. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
