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