Hi,
> very nice. After easter we will provide a daily updated CVS repository
> and a cvsweb interface from our machines. This on popular request by many.
I think I would like to say something additional here.
I don't ( note : I DO NOT ) care about "daily updated" ROOT sources.
I do ( note : I DO ) care about DAILY BUG FIXES.
Current ( actually since ages ) "Root Team" policy is - from time to time
a new "version" of ROOT is released, containing some "bug fixes" and
introducing some "new bugs" ( usually called "improvements" ). Moreover,
as soon as a "new" release is done, "old" releases are not maintained any
more. If this CVS repository is going to follow this schema ( with the
difference that a "new version is released" every day ), then ... .
What I would like to see is a change in the "policy".
Let's take the 2.21 as an example. As soon as it is introduced in the CVS
repository it should become a stable "baseline", updated ONLY with bug
fixes ( as soon as known, of course ). I could imagine that "stable"
release branches are "packed" as separate CVS modules, that means in
separate subdirectories in $CVSROOT subdirectory, for example
$CVSROOT/v2_21 in this case ( forget the /08, it will only harm here ).
The "development" of new ( 2.22, 2.23, ... ) version(s) should/could also
be put into the CVS repository, but again "packed" as a separate CVS
module, for example $CVSROOT/root - note, there is no version, these are
simply always the current, unstable, daily updated, development sources,
regardless of the "current version number".
As soon as the development version is in a "stable" state - it should be
imported into CVS repository as a NEW module, for example
$CVSROOT/v2_22, $CVSROOT/v2_23, ... .
Thus, after some time one would have, for example :
$CVSROOT/v2_21 ( stable 2.21 )
$CVSROOT/v2_22 ( stable 2.22 )
$CVSROOT/v2_23 ( stable 2.23 )
$CVSROOT/root ( unstable, seems in this case 2.24 )
Note - forget the /xx, /yy, /zz from 2.21/xx, 2.22/yy, 2.23/zz.
Finally, the "life time" of a particular release should NOT be "up to the
moment" when the new "stable release" is done. It should be maintained
( BUG FIXES ONLY, of course ) at least for the next 2 "stable" releases.
That means, for example, that the v2_21 should be at least maintained
until the "stable" v2_23 is released. In that moment you could call the
v2_21 "old", the v2_22 "pro" and the v2_23 "new" ( of course the
"unstable" root is always the "dev" release ).
Last, but not least, a file with "known bugs" should be created,
especially if there are bugs that cannot be fixed ( but possibly, with
know workarounds ).
Best regards,
Jacek.
P.S. To "import" a complete tree into CVS just do :
cd $ROOTSYS
cvs -d /cern/root/CVSsrc import -m "ROOT version 2.21/08" v2_21 CERN root_v2_21_08
( note - the FIRST "v2_21" does the trick, NOT the LAST
"root_v2_21_08" )
cvs -d /cern/root/CVSsrc import -m "ROOT version 2.22/xx" v2_22 CERN root_v2_22_xx
cvs -d /cern/root/CVSsrc import -m "ROOT version 2.23/xx" v2_23 CERN root_v2_23_xx
To import the "current unstable" development sources just do :
cvs -d /cern/root/CVSsrc import -m "ROOT Development Sources" root CERN root_development
( note - "root" without version number )
I hope it's correct,
Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:31 MET