Vincent Massol wrote:


-----Original Message-----
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: 12 March 2004 21:09
To: Gump code and data
Subject: Re: [Cactus] commons-codec added to dependency jars?

Vincent Massol wrote:



The way I code is as follows:
1/ make a change on my local machine
2/ verify it works by running some kind of tests

If I don't do 2/ then there is a high chance it will break something

and

I'll only know the following day.

To do 2, there are 2 solutions I can see:
1/ install gumpy locally but that's not very easy to do
2/ have a kind of "self-service gumpy" that you can start on demand

What do you think?

Interesting.

I never though that people would have a problem modifying the metadata
files for fear of breaking gump.

But, I wonder, if your build is already broken, why are you afraid of
breaking it?


In this specific case, it's not broken.

oh, ok.

It's a refactoring (replacing
the dependency on commons-code with some inherit on httpclient). The
problem is that I'm not a gumpy expert and I don't know if this change
is the correct one. Stefan, on the other hand, has had much more
experience and I'm sure he's more confident in the changes he's making
(even though, I'm sure he tries them on his machine from time to time
before or after committing the changes) :-)

More generally, if the build is broken and I make a change to fix it,
I'd like to be sure it fixes the build. Otherwise I'll have to wait till
the following morning, try something else, wait again, try something
else. I remember doing this in the and it took me about 1 week or
more to get Gump working for Cactus (the Cactus build does quite a lot).

man, it took me two months to have a single clean gump run for cocoon, then I let go and it fell apart, so I do feel your pain.

I agree that a sandbox to play would be nice, like having a workflow like:

 1) you log in
 2) click "edit the project descriptor"
 3) a textarea contains the descriptor
 4) you change the descriptor
 5) save it
 6) run the descriptor
 7) get the output
 8) go back to 2) until you are satisfied
 9) commit to cvs

Two problems in this scenario:

1) infrastructure is not going to allow gump to commit to CVS directly
2) since there is no LDAP or equivalent, it's tricky to have a committer-wide access control in synch [even if infrastructure would like to have a single sign-on system in place]

--
Stefano.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to