[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Request for Comments: Proposed changes to Fedora development cycle



Jesse Keating wrote:
On Tue, 16 Oct 2007 17:05:51 +0200
Hans de Goede <j w r degoede 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]