Re: Easter Eggs

From: Pasha Murat (murat@cdfsga.fnal.gov)
Date: Fri Apr 02 1999 - 07:16:55 MEST


hi - what is wrong with the "standard" scheme of using CVS for code 
development?-:

- there is a "main" branch, which contains the "baseline" code corresponding to
  the (releases+bug fixes) and there is a 
  development branch, which is merged from time to time with the main one;
- the bug fixes are put into the baseline version, however
  when the changed "baseline" files are commited, they are also tagged
  with "-b development" in which way fixes propagate into the development
  branch.

In this scenario one needs to maintain binaries only for one public 
(baseline+bug fixes) version. There is also no necessity to put fixes into 
3 independent modules. Fixing the same problem in 3 different versions may 
require different patches so I'd consider it to be a very undesirable feature.

					-pasha


Fons Rademakers writes:
 > Hi Jacek,
 > 
 >    altough in principle agreeing with your proposal, it is currently
 > impossible for our very small team to apply bug fixes to previous versions.
 > Because this implies that we will also get bug reports related to, at
 > least, three different versions, that we will have to debug 3 versions and
 > that we have to maintain binaries for 3 different versions (still the majority
 > of users installs only the binaries). If ever we would get a few more
 > (human) resources we could start thinking about the scheme you proposed.
 > Which indeed makes a lot of sense.
 > 
 > Cheers, Fons.
 > 
 > 
 > > 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.
 > > 
 > 
 > 
 > -- 
 > Org:    CERN, European Laboratory for Particle Physics.
 > Mail:   1211 Geneve 23, Switzerland
 > E-Mail: Fons.Rademakers@cern.ch              Phone: +41 22 7679248
 > WWW:    http://root.cern.ch/~rdm/            Fax:   +41 22 7677910



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:31 MET