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

[Mike Neuffer <mike@i-Connect.Net>]

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'm not so sure I agree with this...but I'll consider it.
> 
> We're already doing this. That's about what we call "standard" or better.

BUT this "standard" as you call it is not conflict free. At the mometn you
can not even on a new install enter the dselect selection screen and leave
it immediately to install only the "standards". It conflicts immeiately on
Perl.
 
> > 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.

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.

Mike


Michael Neuffer                i-Connect.Net, a Division of iConnect Corp.
mike@i-Connect.Net             Home of the Debian Master Server.
mike@debian.org                14355 SW Allen Blvd., Suite 140
503.641.8774                   Beaverton, OR 97005




--
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