Request for Comments: Proposed changes to Fedora development cycle

[Thorsten Leemhuis]

On 17.10.2007 16:06, Jesse Keating wrote:
> On Wed, 17 Oct 2007 07:55:28 +0200
> Thorsten Leemhuis <fedora at leemhuis.info> 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