On Mon 31 Mar 2003 04:41, [EMAIL PROTECTED] posted as excerpted below: > For the 9.0, I remember that there were so my bugs to correct the last > week, Mandrake decided to postpone the final by one week. Everyone agreed > and cheered Mandrake for a good decision. This would be exactly the same to > plan in advance a one week delay, and it would not be a worse attitude than > for the 9.0.
I never really saw the sense in what I am about to propose, other than the politics of it, but as much as I'd like politics not to rule over science and hard logic, the reality is that it does, some times. Why not try NASA's trick? Some minutes before liftoff by the offical clock, IIRC it was at T-4:00, back when the shuttle first came out in the '80s, there was/is a built-in hold. I think back then, it was scheduled at 10 minutes. The thing is, once in the hold, everything had to be green for the hold to be lifted, and the clock to resume. Thus, that 10 minutes could be 15, or 20, or an hour or so. Due to factors such as astronaut fatigue, etc. if it was going to be much longer than 90 minutes, they'd officially call off the launch, stop the clock, and try again later. This seems to be what we are talking about doing here, in effect. You don't have an official launch delay, because the hold time is taken into account, and there is no official "delay". However, the official count-down clock would start seven days off, so, say, 10 days before the offical release (3 days on the count-down clock), there could be a scheduled one week hold -- if anything comes up that could seriously affect the release, it has to come up either before the hold, or at least during it. Then, only when any such show stoppers have been fixed, does the official clock start again, at the 3 day mark. Any last minute changes like the security kernel patch this time around, would then be the only thing made the next two days, that, and minor changes such as the code name, which would be announced when the clock "resumed" so to speak at three days (thus, avoiding the unupdated lsb problem we had this time). One day before official release, then, it should be actually ready for release, and could start appearing on the mirrors, etc, provided no last minute packaging quirks (like the re-used kernel release number, this time around) had been discovered in the previous two days. Thus, d/ls from updated mirrors at T minus one day could normally be said to be the official version, but just might have a packaging bug or two left. Anything after the three-day resumption would have to be a pretty big security fix to get in. The kernel patch this time around might get in on T minus three days, but perhaps wouldn't at T minus two days, and at T minus one day, it would be left as a post release update, as only packaging issues would be changed at that point. As I said, then, folks could d/l at minus a day and know they were getting the final release, but for perhaps a packaging issue or two. Since NASA has already established a precident for this sort of thing, the explanations could simply point to it and say we are doing the same thing, then explaining the built-in one-week hold, which could, under the proper circumstances, mean the clock would NOT be resumed at the three day mark, for a day or two or a week or two after the scheduled resumption. As I said, the scientist/logician in me protests such an idea pretty strongly. However, the politician says it may be an effective solution, whether it's logical to have an offical clock not including that week (or more, if it comes to it) hold, or not. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
