Request for Comments: Proposed changes to Fedora development cycle

[Hans de Goede]

Jesse Keating wrote:
> On Tue, 16 Oct 2007 17:05:51 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> So all in all:
>> -calling it alpha / beta / release candidate instead of test# +1
>> -no freeze for alpha +1
>> -early branching (I would say a week for the RC) +1
>> -making builds in the release branch goto updates-testing after
>>   branching -1 (esp combined with early branching)
> 
> Good, discussion!
> 
> Here is the problem, if the build is not deemed "good" by rel-eng to be
> in the release after the release candidate where does it go?

Why does this deeming good have to be done by rel-eng? Thats creating both a 
bottle-neck and a hoop to jump through.

> Basically
> the idea is that once the RC hits, "development" of the release is
> done, but we want to enable developers to prepare updates to the
> pending release to be able to release them out to updates-testing
> shortly after the release.  Having the builds from the branch be tagged
> as if the release were already out helps in this regard, as they're
> already in the right place to be prepared as an update within Bodhi,
> and if a rel-eng request is made to bring it into the release if
> rel-eng agrees it's a simple tag action to "move it", and if we say no,
> no tagging action is necessary it's all set up to be prepared as an
> update.
> 

Thanks for the explanation I now better understand the problem, so when 
continual frozen prepering for the gold release after an RC, we really want to 
have 3 different options for rawhide builds:
1) Its a benign simple fix, with little chance to regressions, or a fix for a
    blocker bug -> should go into the release
2) Its not next devel cycle material, but it would be better to have it in
    updates-testing when we go gold, then to put it in the release aka
    update-candidate
3) Its next devel cycle material

And the proposed scheme only has 2 exit points, the branch for the release and 
a devel branch. This IMHO is a problem which we should not try to solve by 
introducing human intervention. But rather by a technical solution.

And yes I want to see "benign simple fixes, with little chance to regressions" 
go into the release even once we've released an RC, that way we the actual 
release will be better (less bugs) and we avoid having a slew of updates right 
after the release.

I know some people are very much against this and want only critical fixes at 
this point, to them I say stop thinking Fedora Core and start thinking Fedora 
Extras. For core components like kernel and glibc and xorg I fully agree to the 
only critical fixes stance, but I also fully trust their very capable 
maintainers to only do critical fixes!

So there is no reason why some club should be designated to decide wether or 
not a fix is critical enough. Esp since "wether or not a fix is critical 
enough" is not the only metric to take into account here. The decision should 
be based on weighing the benefits of the bugfix versus the chance of regression 
"multiplied" by the impact of a potential regression. And the person who can 
best judge this balance is the maintainer.

Isn't our new slogan "freedom is a feature", then I say no to a small club 
making the decisions, thats an autocracy. I say power to the people (power to 
the maintainers).

Regards,

Hans