Re: Broken bootable SPARC CD#1, and why this happened
On Thu, 17 Aug 2000, Ben Collins wrote:
> I've gotten reports that the ISO for CD#1 on sparc is completely broken.
> Although the packages and dist files are there, the CD will not boot,
> since almost none of the boot1 files are on the image.
I'd hardly call this "completely broken". I guess you can still do upgrades.
And I hope there are other possibilities to start the install system besides
booting from the CD.
[Please tell me the easiest option, or a precise location in some document, to
refer to on the cdimage.d.o webpages.]
> 1) First of all I think the CD's themselves need a sub revision. Obviously
> if we were to create a new CD image set just for sparc, we can't call
> it 2.2 r0 since there wouldn't be any way to designate it from the
> original broken ones. We can't call it 2.2 r1, since it really isn't,
> and the dist hasn't changed, just the image. So maybe the CD's need to
> be labeled like "2.2 r0 cdv0" (for CD Revision), and in this case we
> could have made "2.2 r0 cdv1" for sparc to fix this.
Oh please!! Unlike some people like you to believe, there exist no revisions
other than CD revisions. There are no FTP revisions. FTP changes _much_ more
than the CDs due to many security fixes. An "FTP revision" indicates the state
of the FTP archive whenever new CDs were made (or whenever some people think
CDs could be made). About 90% of the time the FTP archive does not any longer
match the CDs it is claiming to match. If we counted FTP revisions, 2.1 would
be at revision 30 or something.
So, a 2.2 r1 revision for new Sparc CDs would be the logical choice. However,
I can understand that we would then want a complete series of all
architectures, which isn't necessary at this point.
Therefore, I'd strongly suggest we'd call it 2.2 r0.1 or maybe better 2.2 r0.5
(I hope we won't need a 0.6 then..)
> 2) Next time we create some very important images, I think one person
> needs to be designated responsible for testing images prior to release.
> This requires one of the following:
>
> a) The person download them, burn them, and test an install or two.
> Verify certain points (maybe a checklist...).
> b) If the designated person cannot do this, they can opt to pay for
> images to be shipped to them (Phil, is this too much to ask a
> volunteer? :), then test them.
>
> We have to remember, vendors are burning these CD's almost as soon as
> we make them available. WE are costing them money when we fuck up, and
> it isn't thre fault because they expect these things to work when we
> make them available.
I do agree, but... I think you'll have some trouble finding testers for !=i386
who can a-priori say they'll be available whenever the release manager thinks
the distro is ready. And then making images takes time, testing them takes
time, shipping may take even more time (count at least 4 days for any
international shipping unless you want to pay really much).
> 3) After each arch is tested, that arch is released, independent of the
> other archs. That way we don't slow up everyone else because of slow
> testers.
Do you want to "officially release" a distro, say woody, _before_ the CD
images are available, or _after_ the images are available? I've personally
always opted for the latter. But that would mean the slowest tester is/feels
responsible for all the delay. How to handle that?
Regards,
Anne Bezemer
Reply to: