RFC: Fedora Extras EOL Policy

Michael Schwendt bugs.michael at gmx.net
Fri Apr 14 10:12:21 UTC 2006


Currently, there is a rough proposal of an End-of-Life Policy for Fedora
Extras under review, which is in need of comments from the community of
contributors:

  http://fedoraproject.org/wiki/Extras/Schedule/EolPolicy

In my own words, the plan is:

  In accordance with the Fedora Core life-cycle and with a Security Policy
  for Fedora Extras--which is work in progress, too--we need to
  distinguish between active and legacy versions of Fedora Extras.

  When a release of Fedora Core is transferred to Fedora Legacy, something
  similar is done with the corresponding branch of Fedora Extras.

  The policies for a branch of Fedora Extras, which becomes legacy, would
  be extended in a way which allows for contributions from a _Fedora
  Extras Legacy_ team. These contributors would [be permitted to] take
  over package maintenance where fixes for security vulnerabilities or
  critical bugs are needed and when the primary package owner does not
  wish to do such updates himself.

A few problems need to be discussed and solved:

 * When a release of Fedora Core becomes legacy, not seldomly a Fedora
Extras package maintainer moves on to the current or latest release of
Fedora Core and stops preparing/testing/publishing updates for the legacy
versions. Since not every package maintainer would "support" old legacy
branches, we need a way to mark individual package branches as "free for
adoption by Fedora Extras Legacy". With this comes the need to monitor
corresponding bugzilla tickets of specific branches. It may be necessary
to give legacy branches of Fedora Extras a new "Product" name in bugzilla,
so a default package owner can be different compared with the primary
owner for active releases.

 * While a legacy branch of Fedora Extras, which would be in sort of a
maintenance state, may be kept alive with security and bug fix updates, it
will be necessary to announce its end-of-life when the corresponding
legacy release of Fedora Core is discontinued by the Fedora Legacy
project. We need a policy to shut down a branch finally. Possibly the
buildsys could reject build jobs for such a branch.

 * Do we have enough contributor interest in legacy branches of Fedora
Extras? And if not, are enough contributors interested in building the
Fedora Extras Legacy team? It may be necessary to give it a try to find
out. There are around 1600 packages in owners.list.

 * With terms like "end-of-life", "life-cycle", "maintenance state" come
promises with regard to the expectations raised by our users. It is
important that we don't keep a legacy branch open just because parts of
the contributor community insist on publishing updates for it, while the
majority has moved on to do only the current branches.  What level of
maintenance do we [try to] promise our users? Do we lower their
expectations with regard to a legacy branch of Fedora Extras compared with
an active branch?  If we promise a certain level of maintenance for a
legacy branch (e.g. timely security updates) we need to keep up equal or
higher quality for the active branches, e.g. with policies that lead to
improved response times where package owners are absent/slow/not_responding.

 * During its legacy maintenance state, do we lock a branch, so that no
new packages (i.e. packages which have not been in Fedora Extras before)
may be added? With adding new packages to a legacy branch comes the
promise to maintain those packages in that branch till end-of-life. Else
the workload for the Fedora Extras Legacy team would increase
retroactively. Or we may need to let FESCO judge about it on a
case-by-case basis.




More information about the fedora-extras-list mailing list