Jesse Keating wrote:
On Tue, 16 Oct 2007 17:05:51 +0200
Hans de Goede <j.w.r.degoede@xxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
