Re: Core release test bed (was: Re: Unidentified subject!)

[Richard Jones <richard@a42.deep-thought.org>]

 Mike Neuffer <mike@i-Connect.Net> wrote:	
> On 22 Feb 1997, Kai Henningsen wrote:
> 
> > galenh@micron.net (Galen Hazelwood)  wrote on 21.02.97 in <330E94F7.75EAFF0F@micron.net>:
> > 
> > > > I would just wish that some people would really as I suggested before take
> > > > a close look at what FreeBSD is doing. Defining an essential core system
> > > > (ca. 60-100MB installed binary size) that contains everything an Unix
> > > > system needs to run _properly_ is an essential step.
> > > >
>  
> > > I can see how the universal source tree would look very appealing.  But
> > > please, please try to understand my point of view.  I'm sure I'm not
> > > the only one who holds it.  Then again, perhaps I am.
> > 
> > I don't think this is quite as problematic as it first looks, as long as  
> > we don't junk what we already have.
> > 
> > That is, keep the stuff separated in packages. Make some policy decisions  
> > that essentially say, standard level stuff must not ever depend on stuff  
> > with lower priority, neither for build nor for use.
> > 
> > And devise a test bed that can batch-compile all the standard packages  
> > from one tree. At least for a release, the test bed must be able to  
> > recreate all the standard packages, from an environment consisting of the  
> > very same standard packages, otherwise no release.
> > 
> > And it doesn't mean any change in what the maintainers or users actually  
> > do, except when we find bugs that way. It should, however, improve release  
> > quality.
> 
> Yes, it would mean, that all maintainers cease to upload binary packages.
> For releases we would need one dedicated machine per architecture that 
> compiles everything and then creates the binary packages which get put on
> the FTP server.
>  
> > If nobody else wants to do it, I could look into the mechanics of such a  
> > test bed. Something like a test bed package, that just needs access to a  
> > local mirror and a large enough bootable partition to work on, so that  
> > everybody who wants to can do this test - the more people do this, the  
> > faster we find those bugs.
> > 
> > Comments?
> 
> Go ahead. But it shouldn't be a package. We already have cvsup as Debian
> package. With it we could simply establish a server that carries the whole
> CVS tree. try to develop some sheme where we only need to download/update
> with CVSUP and then start the compile.
> 


I agree, most of the coding work has been done to put this in place, something 
I would like to see is a gzip wrapper for cvsup which allows local users to 
store their source compressed and still sup from the main source tree (usually 
you would need to keep an entire source tree uncompressed on your system, not 
much fun if you don't own a hard drive company).  A list of packages and their 
current size/date could be used to avoid uncompressing each bit of the tree to 
check if it needed updating.

> The problem with tis sheme is that we need to reorganize the current
> package tree. Essential (standard) packages need to go into one
> directory tree, add-on packages into another, so that you can distinguish
> between them while downloading with CVSUP.
> 


I think reorgansing would be worth it for the benefits of distrib building 
providing by CVS.  CVS enables you to do all types of funky stuff like keeping 
just one tree for stable and unstable (hell you could even have "very stable" 
like some people have mentioned), and build the stable and very stable 
distributions from this (i.e. set a date at which unstable becomes stable and 
simply build a source tree as of that date), I'm not a CVS guru but I imagine 
there would be some way to do a stable + important fixes build also.

Also at the risk of boring repition I will say *again* that a CVSUP type 
source tree not only offers a good way of having a distribution built from 
scratch, it also offers huge bandwidth savings as well as added security (if 
both master and maintainer sites are compromised all the checksumming in the 
world will not help [yeah you could store checksums at 3rd party but then what 
if *they* are compromised as well]), now if you think your site is still safe 
CVS diffs will tell you if something bad is happening to the main tree.

Richard Jones



--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com