Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

["Adam R. B. Jack" <aj...@trysybase.com>]

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

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Stefan Bodewig <bo...@apache.org>]

On Mon, 8 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> 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 <project
> name="commons-httpclient" .. <depend
> 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

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Stefan Bodewig <bo...@apache.org>]

On Mon, 8 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> 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 <project
> name="commons-httpclient" .. <depend
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

["Adam R. B. Jack" <aj...@trysybase.com>]

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 <project
name="commons-httpclient" .. <depend
name="commons-httpclient-old-stable-branch" inherit="all") or rename
projects in order to manage it for folk? It seems better for the active
project to manage this once (with sub-projects having named projects should
they chose) than for sub-projects to attempt to keep track.

If not, it gets into me as a user having to manage VFS ('cos they are too
busy off elsewhere to do such things) and that seems (1) rude [I oughtn't]
(2) messy we'd loose valuable gump runs due to folks trying to keep in
synch.

regards,

Adam

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

["Adam R. B. Jack" <aj...@trysybase.com>]

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 <project
name="commons-httpclient" .. <depend
name="commons-httpclient-old-stable-branch" inherit="all") or rename
projects in order to manage it for folk? It seems better for the active
project to manage this once (with sub-projects having named projects should
they chose) than for sub-projects to attempt to keep track.

If not, it gets into me as a user having to manage VFS ('cos they are too
busy off elsewhere to do such things) and that seems (1) rude [I oughtn't]
(2) messy we'd loose valuable gump runs due to folks trying to keep in
synch.

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

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Stefan Bodewig <bo...@apache.org>]

On Fri, 5 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Stefan Bodewig <bo...@apache.org>]

On Fri, 5 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> 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