The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core release test bed


kai@khms.westfalen.de (Kai Henningsen) wrote:
>
[chooped attribution to me coz I didn't actually say anything in the mail ;) ]
>
> >  Mike Neuffer <mike@i-Connect.Net> wrote:	
> 
> ... and for some reason, I haven't seen that mail  ...

The header was:
Date: Sat, 22 Feb 1997 15:14:46 -0800 (PST)
From: Mike Neuffer <mike@i-Connect.Net>

> 
> > > On 22 Feb 1997, Kai Henningsen wrote:
> 
> > > > 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.
> 
> No way.
> 
> That would mean that *everybody* who wants to test unstable needs to build  
> at home.
> 
> I really, *really* hate that idea.
> 
> Keep the current source and binary packages for unstable. For releases ...
> 


This is not what Mike meant, at home the developer keeps the source to the 
package they are responsible for [at a minimum, they could keep the whole tree 
if they liked], they then CVS update to the main source tree when they make 
changes (or they offer these changes for review if its decided developers 
can't be trusted to make their own commits).  Now the main source tree can 
rebuild binary packages from there.  Only those packages that have source 
changed need to be rebuilt, this is no problem, binaries should be able to be 
moved to unstable just as quickly (probably more quickly) than they currently 
are, hence the individual who wishes to test stable but not build from source 
is well and truly catered for.


> > > 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.
> 
> ... do this.
> 
> > > > 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
> 
> Of course it should. That's how we make stuff available. And I see no  
> reason at all why we would not want to make this available.
> 

I think "shouldn't be a package" meant that there is no need for a brand new 
built from scratch program/package, we can use cvsup.

> Cvsup may be nice, but this is the interface between our packages (binary  
> and source alike) and cvsup, or whatever we'll use.
> 
> Cvsup doesn't grok .dsc/.deb, and dpkg{-*} doesn't grok cvsup.
> 

The CVSup idea as I see it doesnt address binary packages that much (except in 
that it could/should build them from source), I don't see CVSup as a tool for 
manipulating binary packages, dpkg should continue to do that job.  However 
dpkg's current support for source packages is IMO limited, and rather than 
creating a new system to deal with source, why not use an existing working and 
powerful system?


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