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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
