Hi Josip, Summary of this note: OK, you don't want to go back to an unfrozen state, you just want to cancel the current test cycle. I don't. It's not yet out of the prep phase. It will be when cd images for the test phase are officially available. Once they become available, they get released absolutely verbatum if it's decided to release after the first evaluation.
--- OK, I think we're closer to agreement than I originally thought, but still several points remain. I haven't read the thread I started fully yet, but will do so before sending this. OK, read it. Apparently, your message was in response to a bug filed against the kernel. Having read Mike Bilow's message about bug 63946, I agree that the bug is release critical. I don't necessarily agree that any change to the image is warranted. We have to draw the line somewhere, and it would be nice to move forward a step. You are suggesting we move at least 2 steps back, once for the cancellation of the test cycle, and again for altering the way it's done, which might cause a major step back: to cancel the whole test. I still hold to my main point, that if you invalidate the algorithm of the test (which is what you are suggesting), you invalidate any test which at any time used that algorithm. > Date: Sun, 14 May 2000 16:26:05 +0200 > To: Jim Lynch <[EMAIL PROTECTED]> > cc: Richard Braakman <[EMAIL PROTECTED]>, debian-devel@lists.debian.org, > debian-release@lists.debian.org > From: Josip Rodin <[EMAIL PROTECTED]> > Subject: Re: Formal objection: Changing how the testing of potato works would > invalidate the whole test. So please don't change it. > > On Sun, May 14, 2000 at 06:32:28AM -0700, Jim Lynch wrote: > > > Almost two weeks have passed since this test cycle began, so this would > > > see > m > > > to be the time to make that evaluation. > > > > > > Since the archive move and all the related trouble related to it happened > > > exactly during the test cycle, the schedule is a bit disturbed (two > > > Incomings etc), but we shouldn't let these problems delay the release any > > > longer than it already has to be :) > > > > ahh :) the usual complaint on the length of time :) what you didn't realize > > is what you are suggesting would delay the release -much- more than just > > being patient :) > > Actually, it won't, you misunderstood my intent. Read below... > > > > How about this for the next plan: > > > > How bout reality for this plan :) which is: the first test cycle's > > preparation phase has not ended yet :) When the boot floppies are ready > > and the images are ready, then we begin testing the whole dist. > > All boot-floppies are ready (except ARM, but that's an opaque thing :), and > the CD images have been created. So, we can test potato installation and > upgrade with those. The images have been created? This hasn't been announced to my knowledge; I looked at the web site you cite (within cdimage.debian.org) in another note and it says that such images are not officially available yet. Does anyone have more current info? If images are -officially- available, let's go with the first test phase. Otherwise, let's have some patience while stability increases. > > But you actually mean "when we freeze and test woody" by "the next plan". > > Right? :) > > Say what? I don't understand what you mean. What part didn't you understand? > > > you accept uploads to potato until the new > > > boot-floppies get uploaded > > > > OK, so you don't mean that. So I voice my formal objection to your plan. > > > > I will express some reasoning behind my objection in some paragraphs at the > > end of this. > > > > I think dark noticed that uploads are getting through... So please everyone: > > don't upload to potato without his ok during the freeze! > > I don't think I understand. If we don't upload packages with fixes for > release-critical bugs, we don't get to release packages or the distro. > If we mail dark for each and every RC bugfix we make, that is just going > to slow him (and subsequently the release) down. This is a test cycle. Nothing is supposed to change. If you want to upload something, upload to woody. If you think it's CRITICAL that it get into potato, THEN talk to dark. Else, wait until the test cycle is over. BTW, critical > release-critical, where '>' is defined by increasing severity. > > > (if they do), and then start a new test cycle. > > > People can continue testing with the CD images from the previous test > > > cycle > > > in the meantime (the differences aren't that important for testing > > > installations). What do you think? We are trying to test FINAL RESULTS of what would be released. Therefore, -every single byte- on every image considered for release is "that important". If it is decided to release, then the image that is released will be absolutely identical in every way, byte-for-byte, to what was tested in the preceeding test cycle. (Dark: this is what you were thinking, correct?) > > Some reasons I object formally to Josip Rodin's suggestion that dark loosen > > the freeze: > > Loosen the freeze? I didn't say or want that. I didn't mean to say that > _all_ uploads should be accepted, I meant to say that the _neccessary_ > uploads should be accepted. And _nothing_ is getting accepted right now. You are talking about allowing uploads in something of an unrestricted way without contacting dark. This would constitute a loosening of the freeze. > > I like that dark has chosen to open them. I very much like that dark says > > -nothing- changes during a test cycle. You go changing that now, and you > > might as wel rewrite the whole plan. > > I didn't say we should change anything during a test cycle - I said the test > cycle should end so that then we should change things :) I contend we should not change things. I also claim that the prep phase of the test period is not over and will not be until official images are available. If anyone knows different about availability of official test images, I would be most interested. Have cd writer, will burn much. > > Oh yes, you want to unfreeze too. > > No, I don't, FFS! Was my post _that_ unreadable? Your intent is fairly readable... you want to hurry up the process, and you're chomping at the bit to upload more stuff into potato. If you have something that is critical to upload, tell dark. He will then respond as to whether you may upload or not. > Oh well. Quisque suorum verborum optimus interpres. Translation? With apologies, I only speak english and don't read latin. > > I hope that during the evaluation phase, it is -decided- what packages > > get in, and potato does -not- effectively become unfrozen > > The release manager decides what packages get into frozen no matter what. > And he makes the judgement by processing the packages in Incoming, and > reading their changelog entries. > > Currently, he isn't processing them at all That is as it should be. NOTHING changes during the test cycle. > , and that will change after the > test cycle ends. I was saying that the test cycle should end, and that a new > cycle should start after some amount of time. Effectively, you're asking dark to cancel the test phase, and it seems you are doing so because you are somewhat impatient. Please relax! Read again how dark wants to conduct the test. > > , i.e., by dark taking Josip's suggestion, that dark would "accept uploads > > to potato" at any time during freeze that is in any way new features or > > code, or unimportant fixes; that is, not release critical. > > Gah. You clearly misunderstood. I'm sorry for being unclear, but it seemed > obvious to me that `any upload to potato' MUST fix an RC bug. Thanks for the clarification. When you make statements, you need to be very specific. "any" doesn't mean "any for which some condition C applies", so when I read, I can evaluate things properly and correctly. As this clarification reaches me, I see that we're a little closer to agreeing, but not even close to anything that would invalidate the test. I also tend to disagree with anything that would decrease the rigor of the testing, because these tests are THE LAST step before releasing the images. We have a fundamental disagreement if you advocate that. -Jim --- Jim Lynch Finger for pgp key as Laney College CIS admin: [EMAIL PROTECTED] http://www.laney.edu/~jim/ as Debian developer: [EMAIL PROTECTED] http://www.debian.org/~jwl/
