RFC: Fedora Extras EOL Policy

[Patrice Dumas]

> 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

Maybe, before adoption by fedora extras legacy team, it should be possible
to have a possibility for individual contributors that are interested
in older branches of the project to take over maintainance of the older
branches. This could simply achieved by saying so to the maintainer of
the active branches and adding oneself to the owners.list to get the bugs
for that package, import the cvs package and work only on the old branches.

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

I don't think it is really needed in many cases, unless the primary owner 
don't want to get the bugs of the older releases. As long as he doesn't 
have to fix them I think he won't mind receiving the bug reports. I am 
more for a comaintainership with verbal agreement on who do what.

If there are 2 contributors one being the primary contributor which
don't want to maintain old releases, the other being a maintainer interested
in the old packages, it is likely that they would collaborate. I cannot
really imagine the primary maintainer not helping the maintainer
of old versions, and it would also be strange for a maintainer of old
branch to refuse to update the main package when, for example there
is a security issue and the maintainer is on vacations...

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

The only way would be to have a way for packagers to signify that
they don't want to maintain a package anymore, and a way for a maintainer
to step in to maintain the old version. Then count and publish the packages 
that still haven't a maintainer and ask people to sign for being in the
fedora extras legacy team. In my opinion, being in the fedora extras legacy 
team shouldn't involve much more than editing owners.list, and subscribing to
a list where fedora extras legacy bug reports go. Does anybody have anything
else in mind?

I think that the packages should be set to the unmaintained for eol release
by default, such that the owner must actively step in. I don't have a
precise idea on how to do that technically, however.

>  * 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

Why not? If a part of the community is willing to maintain a package, they
should be able to do it.

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

I think we shouldn't promise anything, be it for eol or not eol fedora
extra packages. What we must provide however, is an infrastructure and 
some rules that allows contributors to do te best maintainance possible.
That means allowing for multiple owners, maybe a security/legacy team 
and so on.

>  * 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

I think that it would be right to let packagers who want to to add new 
packages, a packager that wants to add a version for eol fedora 
versions shouldn't be discouraged to do so. But I also agree that it 
should be accompanied by the promise to maintain the package for that 
branch also, at least until he orphans the same package for all the fedora 
versions that are not eol.

In the same way I think that packagers shouldn't be discouraged to 
update to the newest releases, and not only backport security fixes, if
the packager prefers that. And it doesn't cause too much deps issues, of
course.

--
Pat