gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [RT]
Date Mon, 14 Apr 2003 11:27:11 GMT
Nicola Ken Barozzi wrote:
> Sam Ruby wrote, On 13/04/2003 20.25:
> ...
>> Replacing the open call with a urlopen call is required to complete 
>> the current gump workspace definition.  On the machine used to run 
>> gump, this increases the time it takes to run the script from 
>> approximately one second to approximately one minute.  I don't know 
>> about you, but I'm too impatient to tolerate that additional overhead 
>> each time I build a project.  (It certainly would be OK, however, in 
>> batch mode when I do a build all).
> ... and this brings us to the usual <put the descriptor with the project 
> or with Gump> kinda thing.
> The project descriptor describes the project, and thus should be near 
> the project, as the build file is, as the project properties are, as the 
> documentation is. That's simple.

To provide a real world analogy... when I was growing up libraries had 
card catalogs.  These were maintained by librarians, not by authors.

If you look at the Gump descriptors, who maintains them?  Mostly 
bodewig, rubys, and donaldp.

> But...
> Why does Gump want these to be local? Because it uses them. Just as 
> xml-site would want them in CVS to generate all the xml site. As you say 
> getting from the web is awful for Gump, but remember that it sucks too 
> for local builds.
> We are *sharing* data between systems. And duplicating *sucks* *sucks* 
> *sucks*.
> So, what are we gonna do about it?
> _Question_ : Why does Gump need the descriptors?
> /Answer/ : to get projects from CVS.
> That is, *not* to build. If it gets then from CVS, it already has the 
> projects on disk. So the *only* need is to get them from CVS.
> _Question_ : if two systems use the same data, and *both* want to access 
> it, why not make it truly shared?
> /Answer/ : make a database of project descriptors that both Gump and 
> single projects can access. So the projects would need to download the 
> descriptor, and Gump would need to update too from the web, but hey, 
> that's what happens when you do 'cvs update'. This would also be used by 
> other systems.
> So, imagine a common database. Projects that need the descriptor get it 
> via web from that service. Same does Gump, with clever diffs that should 
>  not take more time than a cvs update. And anyone with access can 
> 'commit' descriptors.
> Now, we use CVS as a database. So why not making a CVS repository of 
> these descriptors? You may say that Gump *is* such a place. But hey, 
> what about all the projects that are not Apache? Give them access?
> Yes, you are right, it's reasonable that we have a single repository 
> where these descriptors are stored, and with access to all responsible 
> for it, be it project admins or Gumpers.
> How to do it? Suggestions are open.

There may be other solutions.  One is to design a project definition 
which only contains information on how to do the cvs update, and tells 
where the build information can be found once the update is complete.

There is no reason that we need to stick to a strictly linear

   Gen ... Update ... Make ... Publish


- Sam Ruby

View raw message