Re: M68K boot floppies / CDs
> > One thing that did cost a lot of time was the delay in the 'byhand'
> > install of the update files. Maybe the installer should alert the FTP
> > admins of these files separately? Or whoever uploads files that need
> > manual installation needs to CC: his changes file and perhaps a short
> > rundown on the install to the FTP people. Depends on the FTP people what
> > they feel more comfortable with.
>
> Boot-floppies don't seem to take particularly longer than other
> packages that need manual work, actually. If speed is important,
> then send mail to ftpmaster@debian.org and hope. Theoretically
> there are five of us, but I don't know if gorgo and ibid are
> brave enough to install disksets yet.
Ok, a CC to ftpmaster is definitely reasonable. As to the sense of urgency
WRT boot-floppies: we had quite a lengthy discussion on that with Vincent,
and I just assumed he'd alert the FTP team of last minute things to watch
out for.
> As to what we're comfortable with, please remember that your primary
> line of communication with the archive maintainers is the changelog
> in the .changes file. That's what we see when handling packages.
> In the case of the m68k boot-floppies upload of Dec 14, that was:
>
> * note odd version; not official release - update of m68k boot images
>
> Not much to go on, right? It doesn't exactly shout "Install me in slink!"
> It doesn't explain what's going on. In fact, it looks most like a broken,
> accidental upload. You wouldn't believe some of the stuff that gets
> uploaded to stable sometimes.
Ok, I must have completely missed to understand the point in having
version numbers on packages. The full head of the changes file:
Format: 1.5
Date: Fri, 10 Dec 1999 15:07:21 +0100
Source: boot-floppies
Binary: boot-floppies
Architecture: m68k
Version: 2.1.9.2 <---- not a potato version number (slink.r2 perhaps)
Distribution: updates <---- I can't upload to stable, right?
Urgency: low <---- What's appropriate here?
Maintainer: Michael Schmitz <schmitz@biophys.uni-duesseldorf.de>
Changes:
boot-floppies (2.1.9.2) updates; urgency=low
.
* note odd version; not official release - update of m68k boot images
> I first saw this upload when I was looking through Incoming for late
> arrivals to install in 2.1r4, while Wichert and I were working on its
> release. We had about 3 hours for the whole thing, so I never gave
> it a second thought after coming to the conclusion described above.
The 'not official release' was to say 'don't worry about the odd version
number; slink boot-floppies for r4 are at 2.1.9.12 but m68k did stop
building boot-floppies at 2.1.9.2, this is just an update with new
kernels'. One line was a bit brief for that ...
> The problem at this point (with respect to bug#53683) is that any
> change to slink requires an update to its changelog, and the release
> of 2.1r5. I mentally filed it under "stuff to do for the next slink".
> (And I fervently hope that I won't be the one to have to worry about it
> then, because the situation still isn't clear to me.)
>
> So, what now?
See, that's what I'm talking about all the time. I understand you have to
insist on this procedure, but apparently there are no safeguards in place
to make sure a release only gets the go-ahead after even the last minute
updates that people were asked to do have gone in. If that means to ask on
all arch specific lists (m68k-build for m68k here) to check the current
FTP status on master, so be it. You can even ask a few days in advance
who's likely to be around at release time to look into the archive. If
that's not enough to prevent messups, we'd need to have CD images built
off the archive and tested, for all archs.
My big mistake was to assume it'll be alright, and not announce the
upload to the FTP team and release team to flag it a `don't miss'. But
communication the other way wasn't very helpful either.
What now? This is the second boot-floppies update that didn't go in, in
four point releases. If someone wants to take the files in 2.1.9-0606,
create a new changes file with a more meaningful description and upload
this, please go ahead. It's a simple matter of merging the output of
md5sum and ls and signing the result. I refuse to play this charade any
longer.
Michael
Reply to: