Request for Comments: Proposed changes to Fedora development cycle

[Jesse Keating]

On Tue, 16 Oct 2007 19:45:56 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

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

Because past has proven that given our huge number of maintainers that
not everybody notices we're in a freeze, or cares, and leads to broken
trees.  QA/Releng wants some ability to prevent that from happening
down the final stretch to get the release out.  This is something
common to distributions, not just Fedora.  In fact, the model we're
using is closely modeled after the FreeBSD development cycle.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html#RELEASE-PROC

> 
> > 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).

The past has burned me on having that much trust in /every/ maintainer
thinking that deeply into every change they make at the end game.  More
often than not I just see blanket "build for new upstream release"
happening across every active branch at any time during the process
with no thought to freezes or release cycles.  That's the type of thing
we just don't want to land in our trees during the final stages.

The process /does/ have 3 exit points.  There is a devel/ branch to
build things for the next release, there is the release branch which by
default is used for updates to the release, and if the maintainer is
actually making a thought as to this is a fix they want /in/ the
release they can alert the releng team to this and releng can do the
necessary work (calling a koji command to tag the package, calling the
signing commands to sign the package, making sure there is time to get
it in and actually be picked up in a compose, etc...) to get the build
pulled into the release.

I'm more than happy to add more people to the releng team that would be
willing to make these kinds of decisions so that we have round the
clock/world coverage.  I'm just not ready to leave the collection open
for joe random builder to build things in when we're trying to get a
release out.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/61f29f1b/attachment.sig>