cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cocoon is not gump!
Date Wed, 30 Jun 2004 06:47:37 GMT
Steven Noels wrote:

> On 29 Jun 2004, at 23:53, Sylvain Wallez wrote:
>> In this kind of situation, there is a very heavy process set up to 
>> ensure that *all* source code is available, as long as *all* tools 
>> and operating systems required to build and run the software. Plus a 
>> huge amount of design and test documents to allow people to dive in 
>> years after the original development team has disappeared.
> One might wonder whether this isn't something where 
> consultants/integrators get their money from. If preservation and/or 
> fall-back is what your customer expects, would that be something he's 
> going to pay for? I'm talking about the preservation aspect here: if 
> we provided sources, how long could the Cocoon community be expected 
> to keep them? At what cost?

It all depends on the project. For the space software I was talking 
about, the customer paid (a lot) for this, including employing people 
that keep the knowledge and regularily replay the build procedures. But 
this is a very exceptional case as they have to operate the satellite 
over our heads during 15 years. I don't think any of the customers of 
Cocoon-related projects would ever want to reach that level of 
maintainability nor pay for it. So all this is more about protecting our 
own asses if some problem ever arises. And we all know that often 
problems do arise, even if the application was well tested at first: 
unexpected load increase, hardware/OS changes, unusual usage scenarios, etc.

> I tend to understand Ralph's point, but OTOH I think providing the 
> build targets to create source jars should be sufficient, and that the 
> actual assembly work should be at the third party's deliberation.


> For third-party, unreleased or patched libs, a coherent naming scheme 
> and offloading procedure should suffice.

A coherent naming scheme is needed, but is archiving in a central 
location necessary (not talking of the infrastructure problems)? When 
you decide to deliver a project using a snapshot, that snapshot is 
generally a recent one (otherwise its changes are likely to be part of 
an official release) and the CVS repository is therefore still available.

Of course the problem is different if the sources weren't fetched and 
archived with the other project sources when it was delivered.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message