Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 07:43:48PM +0200, J.A. Bezemer wrote:
>
> 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.]
Obviously, any install option that != CD would apply there. Atleast, that
would be obvious to me.
> > 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..)
WTF is the difference? Nothing but a naming scheme. It's still a change,
either way you do it, why do you want to nitpick the mechanism?
> > 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).
IMO, well worth it to avoid any future problems of this kind. Or is
quality second priority, and meeting release dates first?
> > 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?
Uh, the official release CD images were not created until after the
symlink change. The distribution is "released" not the CD images. They
come after. The testing and release of those needs some time, irregardless
of the distribution timeline. We can't opt for "hey we released CD's the
same DAY!", over "dist is released, ISO's are coming soon after some
testing". Quality, quality, quality....not superficial release dates.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: