Justification Procedure for BaBar Required Software
                           (fcp 960816)

BaBar computing makes use of various third-party software packages. It can 
be expected, as the experiment and the computer industry evolves, that
there will be changes in which packages are required to obtain and build
BaBar releases. Changes of this sort have implications for many people,
and need to be well-justified, and documented. Thus, this document 
sets out the procedure and some of the considerations for adoption of 
third-party software requirements.

1) Any BaBar developer who sees a need can make a proposal to change
   a requirement. The proposal should be a brief statement giving
   background, proposed action, implications, and justification.
   Before submitting a formal proposal, the proponent
   will optimally already have discussed it with others. If it
   still appears to have merit, the proposal should be transmitted
   to the computing system management.

2) If the computing management is persuaded that the case is compelling,
   the proposal, perhaps with modifications, will be posted to the
   BaBar Computing Environment discussion list. The purpose of this
   is to make the intended implementation widely known, and to permit
   a period of public comment in case there are serious difficulties
   with the proposal which have escaped notice. 

3) Allowing a period of at least a week for comment, and 
   assuming no serious difficulties have been noted, the proposal
   will be signed off by the computing management and become policy.
   The proposal-turned-policy will be maintained for future reference
   on the "Required Software Page", under the "Tools and Utilities"
   page of the BaBar computing system.
   

Comments/philosophy:

   a) "Computing management" refers here to the computing system
      managers, the computing project engineer, and the deputy
      system managers for reconstruction, simulation, online, and
      tools&utilities.

   b) Some of the general considerations on which proposals may be
      judged include: 
      1) Adopt "standard" Unix solutions where reasonable.
      2) Adopt "uniform" solutions otherwise, where reasonable (eg, if we
         have to use gfind on one platform, require it on all
         platforms, rather than supporting a mixture of vendor find and
         gfind, depending on platform).
      3) Exceptions to either of these should have a clear technical
         justification. 
      4) Personal preference is generally insufficient justification for
         adopting a third party package as a requirement (eg, arguments 
         that "I love perl, and hate tcl", or that "I have this great 
         tool, but it uses zyx" would be looked at askance before requiring 
         the collaboration to support yet another product).
      5) Prefer compatibility with other HEP solutions (eg, better to adopt
         similar solutions as CERN experiments rather than orthogonal
         solutions).