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.


+1

For third-party, unreleased or patched libs, a coherent naming scheme and archive.apache.org 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

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Reply via email to