Dale has asked me to forward this to debian-devel to get a wider
response.
------- Start of forwarded message -------
Date: Fri, 6 Jun 1997 07:24:41 -0400 (EDT)
From: Dale Scheetz <[EMAIL PROTECTED]>
To: Guy Maor <[EMAIL PROTECTED]>
cc: debian-qa@lists.debian.org, debian-testing@lists.debian.org,
[EMAIL PROTECTED]
Subject: Re: How to handle updates to bo?
Message-ID: <[EMAIL PROTECTED]>
I like your solution. It involves a minimal amount of change to procedure
while putting adequate brakes and controles on the installation process.
This works for me.
On 5 Jun 1997, Guy Maor wrote:
> How does the testing group want to handle updates to bo?
>
> The current method of foo, foo-fixed, and foo-updates is a pain to
> administer and will be even more of a pain now that contrib and
> non-free are released. I also do not think it has significant gains
> now that most people use dpkg-ftp to keep their system up to date.
>
> There will be many packages going to bo without going to hamm because
> I expect most developers will start migrating to libc6. That nixes
> one solution of installing everything to unstable and moving packages
> from unstable to stable once they have been tested.
>
> The simplest solution (for me anyway) is to update bo now that it is
> called stable in a similiar fashion as was used when it was frozen:
>
> A developer produces a package earmarked for stable containing some
> important fix. The developer will most likely be doing a special
> compile just for stable using the altdev packages.
>
> dinstall checks for gross package errors, such as an md5sum mismatch
> immediately, but does not install the package. (it already does
> this.)
>
> Members of the testing group install the package out of Incoming. I
> can easily arrange for debian-qa to receive an abbreviated copy of the
> install report that dinstall already sends to Brian and myself. That
> report would contain relevant information about all the packages
> destined for stable that are currently in Incoming.
>
> The testing group decides the fate of the package and Brian invokes
> dinstall to install or reject it.
>
> If the package is installed, dinstall places it directly into the bo
> distribution and automatically updates the ChangeLog. Once a day, the
> daily cron scripts update the Packages files. If they see that new
> packages have been added to bo, they stamp the ChangeLog with the
> version number and update the top-level version symlink.
>
> New versions of bo are thus created as fast the testing group wants to
> create them. An important security fix can be installed immediately
> forcing a version update. Fixes of lesser important can wait in
> Incoming until enough of them are there to justify a new release.
>
> Comments, especially from Brian, please.
>
>
> Guy
>
------- End of forwarded message -------
I have since thought of one minor change. Rather than actually
installing the package with dinstall, Brian can move it it to a
special incoming directory and dinstall can install it in its daily
run. This will eliminate the too-common problem of the Packages file
not matching what is on the archive.
Guy
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
