On 17.10.2007 16:06, Jesse Keating wrote: > On Wed, 17 Oct 2007 07:55:28 +0200 > Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > >>> We have to stop changes in order to finalize >>> the release and get it out the door. >> A week IMHO should suffice. If it doesn't I'd say we need more point >> in the middle to bring rawhide at least in a better shape beforehand. > I think you severely understimate the amount of time it takes to > compose trees, We drifted of and talk on cross purposes (as we two often do when discussing...). So let's try differently: - yes, sure, I know and accept that it takes more then a week to finalize and publish the *final* release - for a test-relase a week should suffice (that's actually what we used in the schedule in the past; see the initial F7 schedule for example: http://fedoraproject.org/wiki/Releases/7/Schedule?action=recall&rev=2 ) - I nevertheless think rawhide should not stand still (or nearly still) for more then a week as two many changes are done in between, which results in a massive pile of updates once rawhide opens again, which results in tons of problems at once. Your proposal solves a part of this problem, but it doesn't solve it for real IMHO >>>> Some packagers will thus likely just push their updates into the >>>> current release without testing them in rawhide first. >>> But rawhide isn't the place to test them, >> Sure it is -- at least for me. Here is what I do when I get a new >> upstream release in Fedora: >> >> - test locally (but that's of course always limited, as apps get used >> differently by different people) >> - update cvs for devel and build for rawhide, as rawhide users are >> those that won't yell to much if upstream released something new with >> multiple bugs in it >> - leave it there -- depending how crucial the package is for a few >> days a week some weeks >> - if nothing bad turned up in rawhide (e.g. if the new upstream >> release didn't contain any new bugs) I ship it in F7 updates-testing >> for some days >> - if nothing bad turns up move it to F7 updates proper >> - if that package would be of interest for F6 I would put it in >> updates-testing for F6 at this point (if one would exist) >> - if nothing bad turned some days later up push to F6 updates proper >> Shipping a update in multiple branches at the same time or in F7 >> earlier then in rawhide (because it is blocked for release) seems >> like a bad idea to me (I know, that's the standard behavior for a lot >> of people) -- if upstream got a bad bug in it all our users are >> effected by it and that can easily be prevented by above scheme. > However rawhide is not the place to test F7 issues. No, of course not. But it's IMHO the best and first place to push a new upstream release out, to get that tested. If that works fine for rawhide users then it will likely work well for F7 as well. > You have different > sets of users in rawhide, F8-testing, F7-testing, etc... You need to > have testing by each of those user sets before you can go final updates > for those releases. And that's why we have F<n>-testing, and that's a good thing. But just because we have it it doesn't mean that I have to push a new version to rawhide, F8-testing and F7-testing at the same time, as a new upstream version with lots of bugs will then git more users then needed. > They are different releases with different > userlands and different kernels/runtimes/etc... And the code from upstream is what has the widest impact. If that is full of bugs I'll notice that after pushing it to rawhide; thus I won't release it for F7- and F8-testing and safe users of those branches a lot of trouble; instead I wait for the next upstream release. > [...] >>>> That's bad in >>>> general already; but it's even more bad here, as it also create >>>> EVR-update troubles once the release is done. >>> How can it create EVR-update troubles? Only if maintainers push >>> updates to previous releases before pushing them for the pending >>> release, and even so this is not a new problem, as updates to >>> previous releases happen all the time while the release is a static >>> package set that quickly has "lower" nvrs than the fully updated >>> previous release. Not a new problem, [...] >> No, but with the new scheme it becomes bigger afaics. > I don't see how it will become bigger. We're /shortening/ the amount > of time where builds don't automatically go somewhere, not lengthening > it. I fail to see that. /me takes a closer look at the example schedule F9 hypothetical schedule: Final Development freeze is 20080408 -- thus all updates after that point that are *not* release-critical gets tagged as "updates candidate" afaics (at least that's how I understand it from the description; please tell me if I got something wrong). Thus non-critical stuff doesn't make it into the tree for 23 days (release is scheduled for 20080501). F8: Final freeze is today 20071017; everything from now afaics gets tagged as "updates candidate" until release, which is scheduled for 20071108 -- 22 days So there is not a real difference I can see. And three weeks is a long time -- much updates will get shipped in the still-current releases (e.g. F7) in those weeks; some of them with a higher EVR then what will be on the F8 media later. BTW, now that I see your hypothetical schedule for F9 -- five weeks between beta and RC sounds like a lot; how about a beta 2 half way? > [...] Doesn't look like it's worth to answer the other parts -- you wanted opinions, you got some and I lost interest to discuss them further. Cu knurd -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
