Bunch 'o quickies

[Sam Ruby <ru...@us.ibm.com>]

New machine:

   I've gotten access to nagoya.apache.org.  It is billed as a fast machine
   from Sun.  So far, I've not seen the speed.  Gump runs that take 3 to 4
   hours on Pentium III's seem to take 6 on Nagoya.

Proposed option: parallel copy operations:

   One way to address the speed issue is to do the cleanup and copying of
   build directories in parallel with the checkouts.  In particular, the
   order can be:

     rm -rf  A &; update cvs/A; wait; cp -r cvs/A A &; rm -rf B &; update cvs/B; wait; cp -r cvs/B B &; ...

   This change could bring Nagoya back to parity with a Pentium.

Catastrophic dependency failure insurance:

   Suggestion from Geir Magnusson Jr: if at the completion of every
   successful build, the output jars are copied to a well defined location
   and then this location is used as the source for resolving dependencies,
   then we have a system that automatically upgrades.  I kinda like this
   idea, and am curious what other people think...

   This discussion was motivated by yesterday's xml-xerces build failure...

Defining a few terms:

   I think of gump as a PROFILE.  A set of PROJECTs and TAGs that at least
   one person sees as an interesting configuration.  The proposal
   directory, contains a codebase which while fun to write and useful at
   the moment, I view as totally expendable.  Hopefully other people will
   someday define other profiles of interesting configurations.

   I see a WORKSPACE as corresponding to a physical set of files on your
   hard drive.  Hopefully in the future, the definition of a workspace can
   be produced by combining and subsetting profiles, as well as adding in
   additional projects.

   I see a build TARGET as something you reference to specify what you want
   built.  At the moment, only projects and a special target named "all"
   are defined, but it would be nice if you could define your own subsets

Repositories:

   I've begun work defining the repository in a manner more consistent with
   the way Alexandria does it and yet definine the elements that make up a
   cvs root in a more fine grained manner.  This will allow sourceforge and
   exolab to be considered as a single repository even though there are
   changes to the actual cvs root required when going from one module to
   another.

Future plans:

   Once I get the DTDs for Gump closer to Alexandria's, I still plan on
   spliting this profile out to a separate CVS module with a considerably
   larger base of committers.  I do plan to get back to the Python
   implementation,   I'm also planning on adding in the various exolab J2EE
   projects - hence the motivation for enhancing the way that repositories
   are defined.

- Sam Ruby


---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org

Re: Bunch 'o quickies

["Geir Magnusson Jr." <ge...@optonline.net>]

Sam Ruby wrote:

> Proposed option: parallel copy operations:
> 
>  [SNIP]
>
>    This change could bring Nagoya back to parity with a Pentium.

LOL

> Catastrophic dependency failure insurance:
> 
>    Suggestion from Geir Magnusson Jr: if at the completion of every
>    successful build, the output jars are copied to a well defined location
>    and then this location is used as the source for resolving dependencies,
>    then we have a system that automatically upgrades.  I kinda like this
>    idea, and am curious what other people think...
> 
>    This discussion was motivated by yesterday's xml-xerces build failure...

I like this idea too :)


> 
> Defining a few terms:
> 
>    I think of gump as a PROFILE.  A set of PROJECTs and TAGs that at least
>    one person sees as an interesting configuration.  The proposal
>    directory, contains a codebase which while fun to write and useful at
>    the moment, I view as totally expendable.  Hopefully other people will
>    someday define other profiles of interesting configurations.
> 
>    I see a WORKSPACE as corresponding to a physical set of files on your
>    hard drive.  Hopefully in the future, the definition of a workspace can
>    be produced by combining and subsetting profiles, as well as adding in
>    additional projects.
> 
>    I see a build TARGET as something you reference to specify what you want
>    built.  At the moment, only projects and a special target named "all"
>    are defined, but it would be nice if you could define your own subsets

Yes - and it would be nice to add a 'reference workspace' - (not sure if
this integrates with your definitions...) - the idea is that I would
like to add to the Gump Central Services nightly run arbitrary things
for it to do, where the definition for which is located in my
(Velocity's) CVS.  So I can add little bits when I need something (like
adding something ephemeral, like gumping a release candidate...) and
remove them, w/o having to touch the central gump workspace.  

It also means that each project could take advange of gump's services
w/o needing karma for gump's CVS.

I imagine in implementation that it would be an element of a workspace
that pointed to a workspace definition in a CVS somewhere else.  I will
try and sketch out what I am thinking about...

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.net
Developing for the web?  See http://jakarta.apache.org/velocity/

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org