You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Leo Simons <ls...@jicarilla.org> on 2004/03/23 20:04:44 UTC
[RT] href considered harmful
Fellow gump project members,
the whole build breaking last night because some lameass sourceforge
developer doesn't know how to write gump descriptors (even if it was me)
annoys the hell out of me. It should not be possible. The basic cause
for that happening was the use of the 'href' attribute to link to remote
descriptors accessed via webcvs.
Having descriptors live in avalon and cocoon cvses has proven to be a
bad idea as well -- its just annoying for people working on gump to not
be able to go in and change things, especially when the people with
access to the repositories of those projects are doing a bad time
maintaining the descriptors (even if it was me).
Having descriptors live elsewhere also makes oversight more difficult.
What if some developer changes a descriptor overnight to have him mail
himself (for example) the contents of /etc/groups? It's not like we'll
be able to ever consider a machine which runs gump as secure, but having
all descriptors in one place (under version control) does help a lot,
and also makes it easier to see who screwed something up.
The support for the 'href' attribute complicates an already complex
codebase and slows gump runs down because viewcvs (which is usually used
for this) is often quite slow. This becomes more of an issue when
turning gump into an always on webapp, where we probably want to keep
the GOM in memory or at least in compiled form for good user response.
Descriptors living elsewhere has proven to be confusing for users, and
it has led to duplicate project descriptors on more than one occassion.
With several anoncvs servers (notoriously sourceforge, but its not the
only one) lagging behind the work of the developer, having the
descriptors accessed over anoncvs slows the work of developers down by
heaps when writing or debugging descriptors. Especially because one has
to wait for the server before being able to 'ant verify'. This leads to
a model of commit-then-verify, which is plain wrong.
Gump is a social experiment, and this part of the experiment has shown
to be a negative and annoying factor. I feel that my own recent
experiences with jicarilla are an excellent example: even with an active
and experienced member of the core gump group trying to actively
maintain gump descriptors in sourceforge cvs, things break and the
workflow is nothing short of a nightmare.
I suggest we move to strike and loudly proclaim descriptors not living
in gump CVS as harmful. Their use needs to be *strongly* discouraged
from now on. Who's with me?
--
cheers,
- Leo Simons
(PS: I love writing like this every now and then...it's a writing
exercise; don't take it /too/ seriously :D)
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Pure Python (was Re: [RT] href considered harmful)
Posted by Adam Jack <aj...@TrySybase.com>.
> if I would like to replace the use of ls and cat in gumpy with pure
> python code (like sync), do you have
> any suggestions ?
>
> Do we already have testcases for the use of ls and cat in the tools.py ?
Huh? I think this has already been done (see FileHolder in files.py), I just
left the old code in there (in tools.py). Did I leave tests in by accident
that cause problems? Do you have any real runtime problems? I thought your
sync.py not the last piece in that port to pure.
The only remaining thing I'm aware off that isn't pure Python that ought be
pure is 'pgrep', which is broken anyway and logged into JIRA as such.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Adam Jack wrote:
>
>
>>Gump is a social experiment, and this part of the experiment has shown
>>to be a negative and annoying factor. I feel that my own recent
>>experiences with jicarilla are an excellent example: even with an active
>>and experienced member of the core gump group trying to actively
>>maintain gump descriptors in sourceforge cvs, things break and the
>>workflow is nothing short of a nightmare.
>>
>>
>
>It is a tough decision to remove a feature (like href) that has such
>potential for 'community outreach'. It seems such a good idea (to avoid CVS
>bound, and distribute responsibility) and that it can't be bad, can it? I
>think it can...
>
>I think we have to review exactly where we stand w.r.t to the Gump workflow,
>and recognize that we tried to distribute metadata management too soon for
>the communities. Sure, for an expert Gump metadata is simple, but it does
>have a lot of complex choices (to support reality). The combinatorials of
>Gump metadata (when merged) are quite daunting. With no
>generator/wizards/overviewer/compiler/tester we are expecting the community
>to throw metadata up to us and hope it runs. That is counter productive to
>our goal of happy communities.
>
>Gump metadata is like having a complex development in a runtime interpreted
>language with nightly runs based upon untested code in a repository. This is
>analogous to punch cards & batch runs and requests more
>patience/discipline/investment than communities will give. [Heck, this *is*
>the early days of my writing Gumpy in Python checking in to test remotely,
>prior to getting some unit tests. ;-) Hard, hard, work --a frustrating bad
>development environment.]
>
>
>
Adam,
I agree very much with all you have written.
May I ask you another question :
if I would like to replace the use of ls and cat in gumpy with pure
python code (like sync), do you have
any suggestions ?
Do we already have testcases for the use of ls and cat in the tools.py ?
Cheers,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Adam Jack <aj...@TrySybase.com>.
> Gump is a social experiment, and this part of the experiment has shown
> to be a negative and annoying factor. I feel that my own recent
> experiences with jicarilla are an excellent example: even with an active
> and experienced member of the core gump group trying to actively
> maintain gump descriptors in sourceforge cvs, things break and the
> workflow is nothing short of a nightmare.
It is a tough decision to remove a feature (like href) that has such
potential for 'community outreach'. It seems such a good idea (to avoid CVS
bound, and distribute responsibility) and that it can't be bad, can it? I
think it can...
I think we have to review exactly where we stand w.r.t to the Gump workflow,
and recognize that we tried to distribute metadata management too soon for
the communities. Sure, for an expert Gump metadata is simple, but it does
have a lot of complex choices (to support reality). The combinatorials of
Gump metadata (when merged) are quite daunting. With no
generator/wizards/overviewer/compiler/tester we are expecting the community
to throw metadata up to us and hope it runs. That is counter productive to
our goal of happy communities.
Gump metadata is like having a complex development in a runtime interpreted
language with nightly runs based upon untested code in a repository. This is
analogous to punch cards & batch runs and requests more
patience/discipline/investment than communities will give. [Heck, this *is*
the early days of my writing Gumpy in Python checking in to test remotely,
prior to getting some unit tests. ;-) Hard, hard, work --a frustrating bad
development environment.]
> I suggest we move to strike and loudly proclaim descriptors not living
> in gump CVS as harmful. Their use needs to be *strongly* discouraged
> from now on. Who's with me?
I think we are in a state where this is a good thing, for those that can.
Gumpmeisters need to help communities (until we code tools, wizards/whatever
to help generate that.) I don't think 'hrefs' are themselves the core
problem, but deprecating them help bring things into the hands of the
experts, so I am for it.
> (PS: I love writing like this every now and then...it's a writing
> exercise; don't take it /too/ seriously :D)
;-)
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump-Check task
Posted by Martin van den Bemt <ml...@mvdb.net>.
Isn't LocalCheck (the java Gump) already doing (at least locally on the
gump box), but this should be extendable to do remotely. But I guess you
were discussing Gumpy :).
Mvgr,
Martin
On Wed, 2004-03-24 at 18:12, Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
> > Maybe we could have an ant task that talks to the gump repository to
> > keep (nay, improve on) that functionality.
> >
> > <project default="test">
> > <target name="verify-gump" depends="build">
> > <gump-check project="cocoon"/>
> > </target>
> > <target name="test" depends="build,verify-gump">
> > </target>
> > </project>
> >
> > the gump-check task would get a list of requirements from the gump
> > server (ie, what jars should exist, what directories, licenses, ...)
> > and compare that info to the filesystem. It would warn the user of any
> > errors.
> >
> > Like Ozzie, I'm just a dreamer ;)
>
> Let's keep dreaming.
>
> Gump looks closer to any port-like system that is out there for java
> stuff. We happen to have a huge amount of metadata and the automatic
> ability to make sure it remains in synch with it.
>
> it would *NOT* take much to do what leo is suggesting and solve the jar
> distribution thing.
>
> worth thinking about!
--
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump-Check task
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> Maybe we could have an ant task that talks to the gump repository to
> keep (nay, improve on) that functionality.
>
> <project default="test">
> <target name="verify-gump" depends="build">
> <gump-check project="cocoon"/>
> </target>
> <target name="test" depends="build,verify-gump">
> </target>
> </project>
>
> the gump-check task would get a list of requirements from the gump
> server (ie, what jars should exist, what directories, licenses, ...)
> and compare that info to the filesystem. It would warn the user of any
> errors.
>
> Like Ozzie, I'm just a dreamer ;)
Let's keep dreaming.
Gump looks closer to any port-like system that is out there for java
stuff. We happen to have a huge amount of metadata and the automatic
ability to make sure it remains in synch with it.
it would *NOT* take much to do what leo is suggesting and solve the jar
distribution thing.
worth thinking about!
--
Stefano.
Gump-Check task (was: Re: [RT] href considered harmful)
Posted by Leo Simons <ls...@jicarilla.org>.
Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
>> I suggest we move to strike and loudly proclaim descriptors not living
>> in gump CVS as harmful. Their use needs to be *strongly* discouraged
>> from now on. Who's with me?
>
> I agree with you as a general principle.
>
> Too bad that the entire cocoon build system relies on the gump
> descriptor for its blocks and this is going to be so for a while.
>
> If you deprecate href, cocoon will be seriously damaged.
who said anything about deprecate? I said its harmful, that's different.
I consider the use of static factories in java applications harmful, but
its not like static methods will be deprecated anytime soon! :D
I think no-one wants to actually disable the ability to use href.
> Now, I am the one to blame for this, but my rationale was to keep gump
> and cocoon in synch by making sure that everytime you built cocoon, you
> were also testing if the gump descriptor was right.
>
> Of course, only gump can do the full check, but the cocoon build can
> help a little bit.
hmm. Good point.
You want the ability to verify a project state is consistent with what
gump expects it to be after a build, but only gump can verify that.
Maybe we could have an ant task that talks to the gump repository to
keep (nay, improve on) that functionality.
<project default="test">
<target name="verify-gump" depends="build">
<gump-check project="cocoon"/>
</target>
<target name="test" depends="build,verify-gump">
</target>
</project>
the gump-check task would get a list of requirements from the gump
server (ie, what jars should exist, what directories, licenses, ...)
and compare that info to the filesystem. It would warn the user of any
errors.
Like Ozzie, I'm just a dreamer ;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Project descriptors (was Re: [RT] href considered harmful)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
>> I suggest we move to strike and loudly proclaim descriptors not living
>> in gump CVS as harmful. Their use needs to be *strongly* discouraged
>> from now on. Who's with me?
>
> I agree with you as a general principle.
>
> Too bad that the entire cocoon build system relies on the gump
> descriptor for its blocks and this is going to be so for a while.
>
> If you deprecate href, cocoon will be seriously damaged.
>
> Now, I am the one to blame for this,
Actually I was the one that started it ;-P
History: when I needed a descriptor for Centipede, I looked at the Gump
one, and extended it. Then Cocoon needed a similar system, so out of my
experience with Centipede I created the code-generating block build
system....
> but my rationale was to keep gump
> and cocoon in synch by making sure that everytime you built cocoon, you
> were also testing if the gump descriptor was right.
...that was what I thought...
> Of course, only gump can do the full check, but the cocoon build can
> help a little bit.
... and here is where it broke. The fact is that the two are now so
different in the way they work that the check is not good enough.
Or we make the Cocoon build system more akin to Gump, or we make
something that keeps the two descriptors lazily in synch.
Stefano, I need your help. We've been banging our head on this for
months, and I still remember a discussion like this with Sam more than a
year ago. We *must* resolve this.
Let's see:
1. Gump needs to have all the descriptors at hand. Href is too volatile
for Gump.
2. Gumpers need to be able to change that information.
3. Project developers need to be able to change that info too.
4. The two descriptors should be able to stey out of synch.
So:
From point 1 and 2 we need a repository with all the descriptors.
From point 3 and 4 we need to have a replication system between the
repository and the project.
Let's say that each project has a Gump descriptor in the Gump repo and
*can* *also* have an href. A cron job can check the two and report the
differrences to the respective communities (ie the one that has the
oldest descriptor). In this way we have bi-community peer review of changes.
Even better, on every descriptor checkin, a quick build is performed
with last night's jars, to see that the descriptor works. But this is
part of the -build per checkin- thing that is on the agenda in any case.
So, is this an option. Let's get this nailed :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> I suggest we move to strike and loudly proclaim descriptors not living
> in gump CVS as harmful. Their use needs to be *strongly* discouraged
> from now on. Who's with me?
I agree with you as a general principle.
Too bad that the entire cocoon build system relies on the gump
descriptor for its blocks and this is going to be so for a while.
If you deprecate href, cocoon will be seriously damaged.
Now, I am the one to blame for this, but my rationale was to keep gump
and cocoon in synch by making sure that everytime you built cocoon, you
were also testing if the gump descriptor was right.
Of course, only gump can do the full check, but the cocoon build can
help a little bit.
--
Stefano.
Re: [RT] href considered harmful
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 24 Mar 2004, Leo Simons <ls...@jicarilla.org> wrote:
> Stefan Bodewig wrote:
>> There may be the issue of "ownership", though. "I don't want
>> anybody to modify *my* descriptor". Not in the domts case, but it
>> could become an issue and maybe even is today.
>
> well, that's an attitude I don't like!
Neither do I, but let's be realistic. Even inside some Apache
projects you have places with "this is my code/project - ask before
you touch anything" attitudes.
> The gump (and wider open source) community owns gump, and that
> includes its descriptors. Participating in gump is participating in
> that community, according to our rules.
>
> agreed?
Say Gump builds project A since it depends on many Apache projects and
is used by many Apache projects. Do you prefer to take care of a
descriptor for it not knowing anything about A or to let the people
behind A maintain it?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Leo Simons <ls...@jicarilla.org>.
Stefan Bodewig wrote:
> On Wed, 24 Mar 2004, Leo Simons <ls...@jicarilla.org> wrote:
>
>>>No webapp would enable anybody to put a different license on the
>>>descriptor, for whatever reason he/she should choose to do so.
>>
>>do you really think that will actually become an issue?
>
> Not really. There may be the issue of "ownership", though. "I don't
> want anybody to modify *my* descriptor". Not in the domts case, but
> it could become an issue and maybe even is today.
well, that's an attitude I don't like! The gump (and wider open source)
community owns gump, and that includes its descriptors. Participating in
gump is participating in that community, according to our rules.
agreed?
>>Do you think Curt Arnold would object to moving the descriptor, for
>>example?
>
> I asked him where he wanted to put it. Since Curt is no Apache
> committer but wanted to be able to maintain it, he decided to put it
> on the W3C box.
which is a good reason. Once we agree on the basic principles we can
figure out how to make the technology support that :D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 24 Mar 2004, Leo Simons <ls...@jicarilla.org> wrote:
>> No webapp would enable anybody to put a different license on the
>> descriptor, for whatever reason he/she should choose to do so.
>
> do you really think that will actually become an issue?
Not really. There may be the issue of "ownership", though. "I don't
want anybody to modify *my* descriptor". Not in the domts case, but
it could become an issue and maybe even is today.
> Do you think Curt Arnold would object to moving the descriptor, for
> example?
I asked him where he wanted to put it. Since Curt is no Apache
committer but wanted to be able to maintain it, he decided to put it
on the W3C box. This issue could be resolved by a webapp or granting
karma to Curt.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Leo Simons <ls...@jicarilla.org>.
Stefan Bodewig wrote:
> On Tue, 23 Mar 2004, Leo Simons <ls...@jicarilla.org> wrote:
>
>>The basic cause for that happening was the use of the 'href'
>>attribute to link to remote descriptors accessed via webcvs.
>
> The basic cause was that somebody modified a descriptor without
> checking whether anything got broken by the change. ;-)
hehehe. True. I probably meant "root cause" or something like that...it
is too difficult to check.
Also, the check cannot be automated, its something a human has to do (bad).
> On the other hand, href has some potential that we shouldn't throw
> away. The ant-contrib project has two descriptors that are more or
> less maintained by me, no big deal, but take a look at the dom
> testsuite descriptors. Curt Arnold has written them.
>
> In particular, look at the very top of the descriptor for the
> copyright message and the license - this could never live in a Apache
> metadata module for legal reasons. Well, maybe it could since the
> license is less restrictive than the ASL, but you get the point. No
> webapp would enable anybody to put a different license on the
> descriptor, for whatever reason he/she should choose to do so.
do you really think that will actually become an issue?
I can't really imagine why someone would want to put an AL-incompatible
license on a descriptor that is used by an ASF project to build said
project on ASF hardware.
Do you think Curt Arnold would object to moving the descriptor, for example?
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 23 Mar 2004, Leo Simons <ls...@jicarilla.org> wrote:
> the whole build breaking last night because some lameass sourceforge
> developer doesn't know how to write gump descriptors (even if it was
> me) annoys the hell out of me. It should not be possible.
Absolutely true. Gump shouldn't break.
Note that this is not limited to Gumpy, "traditional" Gump dies in
Jenny as well when a circular dependency has been detected - it's just
that our Gump installations went on and used the generated build.sh
and update.sh files of the night before.
> The basic cause for that happening was the use of the 'href'
> attribute to link to remote descriptors accessed via webcvs.
The basic cause was that somebody modified a descriptor without
checking whether anything got broken by the change. ;-)
href adds to this problem a lot, I agree. If you modify a descriptor
that is in Gump's module, you can run "ant verify" before you commit
the change - this is a lot harder to do (custom profile) if your
descriptor is referenced via href.
And delays like we still see them for anoncvs at sourceforge certainly
make things worse.
On the other hand, href has some potential that we shouldn't throw
away. The ant-contrib project has two descriptors that are more or
less maintained by me, no big deal, but take a look at the dom
testsuite descriptors. Curt Arnold has written them.
In particular, look at the very top of the descriptor for the
copyright message and the license - this could never live in a Apache
metadata module for legal reasons. Well, maybe it could since the
license is less restrictive than the ASL, but you get the point. No
webapp would enable anybody to put a different license on the
descriptor, for whatever reason he/she should choose to do so.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] href considered harmful
Posted by Leo Simons <ls...@jicarilla.org>.
Scott Sanders wrote:
>>Descriptors living elsewhere has proven to be confusing for users, and
>>it has led to duplicate project descriptors on more than one occassion.
>
> What about projects which do not contain an apache committer?
>
>>I suggest we move to strike and loudly proclaim descriptors not living
>>in gump CVS as harmful. Their use needs to be *strongly* discouraged
>>from now on. Who's with me?
>
> I am +1 for apache projects, since our cvs is open to all committers, but
> how do we handle others?
that's the next step, on which I have some ideas ("run a seperate, less
safe, svn installation for gump meta" is one, "provide a webapp" is
another), but nothing concrete yet. Do you have any ideas?
Note I didn't actually suggest any implementation changes (like, "remove
GOTO from the language")...yet. I just pointed at a problem :D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: [RT] href considered harmful
Posted by Scott Sanders <sa...@apache.org>.
> Descriptors living elsewhere has proven to be confusing for users, and
> it has led to duplicate project descriptors on more than one occassion.
>
What about projects which do not contain an apache committer?
> I suggest we move to strike and loudly proclaim descriptors not living
> in gump CVS as harmful. Their use needs to be *strongly* discouraged
> from now on. Who's with me?
>
I am +1 for apache projects, since our cvs is open to all committers, but
how do we handle others?
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org