Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 04:10:53PM +0100, Philip Hands wrote: It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. In which vein, it might be helpful to have test machines around. Given enough warning, I'd normally be able to lend Phil a sparc for the duration of the CD test cycle, for example. Or it's possible that next year I'll have a sparc on a fast connection; one of the two. I suggest that before next time we go through this rigmarole we try to isolate definite testing volunteers for each architecture (for slink, for example, Steve not only burnt some sparc CDs for me to test, but gave me a SCSI CD to test them with...). Jules
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 07:43:48PM +0200, J.A. Bezemer wrote: 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. Huh? Security fixes go in security.debian.org and proposed-updates, and only get included onto the distribution proper when we make a new revision. The reason we do this is mainly for CD vendors, but we do it to the archive too. Or, at least, that's my understanding. I've never paid that much attention to stable once released though. And what's with the unlike some people like you to believe nonsence? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpxRD21apKPE.pgp Description: PGP signature
Broken bootable SPARC CD#1, and why this happened
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. Now I could blame this on Phil, who created the images, but that wouldn't be right, since he can't be expected to know what a bootable sparc image looks like, nor does he even have a sparc to test this on. I could blame myself, but the fact is the image was not created right (it needs to be done as either root, or under fakeroot, which requires the *entire* process be done in a single session, not multiple fakeroot incantations, which might be the cause here), and I could not have been expected to download 650megs over my 33.6k modem within the few hours timeframe that these things were created and distributed under. I could blame... Well, you get the point. I don't want to place blame. I just don't want to see this shit happen again. Here's what I want to see next time (2.2 r1): 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. 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. 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. 4) From here, things should be handled a lot better AFA mirroring (before being made world readable to the public), but I'll leave that to the debian-cd folks to decide how to make that better. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 06:31:04AM -0400, Ben Collins wrote: Well, you get the point. I don't want to place blame. I just don't want to see this shit happen again. Here's what I want to see next time (2.2 r1): Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. YMMV. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgp2uoHRX1qJO.pgp Description: PGP signature
Re: Broken bootable SPARC CD#1, and why this happened
Ben Collins [EMAIL PROTECTED] writes: I could blame myself, but the fact is the image was not created right (it needs to be done as either root, or under fakeroot, which requires the *entire* process be done in a single session, not multiple fakeroot incantations, which might be the cause here), and I could not have been expected to download 650megs over my 33.6k modem within the few hours timeframe that these things were created and distributed under. A couple if nits to pick: Firstly, I did build them under fakeroot. (admittedly there were some images that I forgot to do that for for a while, but they were not linked to the 2.2_rev0 tree IIRC, and if they were, they certainly were not accompanied by a signed MD5SUMS file). Are we talking about the ones that match the signed MD5SUM? Secondly, if you'd downloaded the TC3 images, you should have been able to rsync the new image in about 2 hours (or possibly less) over a 33.6k modem. If the official CDs really are broken, then I imagine the TC3 ones were too. Is that the case? How come we didn't spot that? If we did spot that, and it passed me by, then I'm sorry, but knowledge like this needs to be encapsulated in debian-cd, so my near infinite capacity to screw things up gets little room for manoeuvre. We need a root check for sparc builds in the debian-cd Makefile so that it screams about not being able to make bootable CDs (because I'm afraid expecting me to remember details like that is just going to mean this keeps happening, because this stuff generally gets done too late at night) Other than that, I agree with you. Cheers, Phil.
Re: Broken bootable SPARC CD#1, and why this happened
Hi, a side note, but I think an important one. Ben Collins wrote: 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. Uh, it is entirely their fault if they don't test what they ship prior to shipping. Debian is not making guarantees about the usuability of the stuff we distribute. This said, I think you have good ideas how to improve the process. Thanks, Marcus
Re: Broken bootable SPARC CD#1, and why this happened
Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil.
WG: Broken bootable SPARC CD#1, and why this happened
Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Philip Hands [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:11 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: Re: Broken bootable SPARC CD#1, and why this happened Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: Broken bootable SPARC CD#1, and why this happened
Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:36 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: WG: Broken bootable SPARC CD#1, and why this happened Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:Philip Hands [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:11 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff:Re: Broken bootable SPARC CD#1, and why this happened Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: Broken bootable SPARC CD#1, and why this happened
Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:41 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: WG: Broken bootable SPARC CD#1, and why this happened Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:36 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff:WG: Broken bootable SPARC CD#1, and why this happened Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Philip Hands [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:11 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: Re: Broken bootable SPARC CD#1, and why this happened Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WG: Broken bootable SPARC CD#1, and why this happened
[EMAIL PROTECTED] writes: Not for me... Life is nice isn't it? (And then stop sending this Not for me-answers all the time or something bad could happend) -- Peter
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 04:10:53PM +0100, Philip Hands wrote: Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). Can I ask why the box was so unreliable? We tout our distribution, and Linux presents itself generally, as a rock-solid stable operating system. Why all the crashes? Bad hardware? -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | pgpzsikaaDBzo.pgp Description: PGP signature
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
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, qualitynot superficial release dates. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Broken bootable SPARC CD#1, and why this happened
Ben Collins [EMAIL PROTECTED] writes: 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? Personally, I'd favour doing something that makes it as clear as possible that it was a CD production SNAFU, and that hence the sparc images are exactly the same revision as all the other ones, just that we had to have two (or in fact three, but we'll forget about that) runs at making the images. The FTP archive is not being updated by one jot in between the CD build runs, so when I make another set of sparc (and perhaps alpha) they will still be CDs of Debian 2.2 rev0, not rev0.1, not rev0.5, not rev1. On that basis, I'll call the directory on cdimage.d.o: 2.2_rev0_cdrev1 I'm not certain what I'll put on the CDs themselves, because I need to check the size issues, but if it will fit, I'll go for something like: 2.2 r0 CDr1 2.2 r0 (1) 2.2 r0.1 and if it's likely to cause the slightest problem, I'll not bother changing the version at all on the CD. All right? (I'm not overly bothered if that's not all right, given that there's probably not time to discuss it further before I do it). Cheers, Phil.
Re: Broken bootable SPARC CD#1, and why this happened
On 17 Aug 2000, Philip Hands wrote: Ben Collins [EMAIL PROTECTED] writes: 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? Personally, I'd favour doing something that makes it as clear as possible that it was a CD production SNAFU, and that hence the sparc images are exactly the same revision as all the other ones, just that we had to have two (or in fact three, but we'll forget about that) runs at making the images. The FTP archive is not being updated by one jot in between the CD build runs, so when I make another set of sparc (and perhaps alpha) they will still be CDs of Debian 2.2 rev0, not rev0.1, not rev0.5, not rev1. On that basis, I'll call the directory on cdimage.d.o: 2.2_rev0_cdrev1 I'm not certain what I'll put on the CDs themselves, because I need to check the size issues, but if it will fit, I'll go for something like: 2.2 r0 CDr1 2.2 r0 (1) 2.2 r0.1 and if it's likely to cause the slightest problem, I'll not bother changing the version at all on the CD. All right? (I'm not overly bothered if that's not all right, given that there's probably not time to discuss it further before I do it). Okay; I think r0.1 will be the only thing fitting nicely in the disklabel (32 bytes), as powerpc-sparc=2 ;-) (And then hope that powerpc doesn't need a second set...) Regards, Anne Bezemer
Re: WG: Broken bootable SPARC CD#1, and why this happened
Peter Makholm [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Not for me... Life is nice isn't it? (And then stop sending this Not for me-answers all the time or something bad could happend) I would guess thats a mial loop, like an away message. MfG Goswin
Re: WG: Broken bootable SPARC CD#1, and why this happened
On Fri, Aug 18, 2000 at 02:39:26AM +0200, [EMAIL PROTECTED] wrote: Peter Makholm [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Not for me... Life is nice isn't it? (And then stop sending this Not for me-answers all the time or something bad could happend) I would guess thats a mial loop, like an away message. Except that one of the messages had a capital 'F' in 'For'... -- - mdz
