Patrice Dumas wrote:
Hello,
I thought about a plan regarding Updates After End of Life (UAEL,
temporary name for the project). I think that first we should make sure
that all the packages in the comps groups 'Core' and 'Base' that are not
optional + kernel have a maintainer for that branch. Then we would
automatically generate a list of all the packages that have UAEL branches
and advertise UAEL to be that set of packages, and nothing more.
The text for UAEL could be like
"Updates After End of Life is a volunteer based project which aim is to
maintain packages after Fedora End of Life selected on a volunteer basis.
A package is available if there is a volunteer to maintain it. The packages
currently maintained are listed below. A volunteer may stop maintaining a
package, in which case it will be removed from the list. A whole branch
is discontinued when one of the packages that defines a minimal fedora
system isn't maintained anymore (a minimal system is defined as a system
with default and mandatory packages from Core and Base comps groups,
plus the kernel).
The rule for updating packages in this project is not well formalized
and mostly left to the package maintainers. We avoid breaking
compatibility or doing rebuilds for futile reasons, but we don't promise
ABI stability either. It can be thought as a middle ground between
Fedora rate of change and RHEL/Centos/EPEL rate of change.
In case it still wasn't clear from above, it is a volunteer based
project, so there is no guarantee on the lifetime of a branch, a
package to be maintained nor on the rate of package updates."
Now what I propose is to start a wiki page where I list the packages
that are in a Base + Core install, and let people interested put their
name in front of the packages they are ready to maintain. A packager
ready to maintain such a package should at least be approved in the
package database as watchcommit and watchbugzilla for this packages
for branches that are more recent than the branch he intends to
maintain.
When all those packages have a maintainer ready, we
* find a definitive name for the project
* start a SIG (with, at least all the maintainers of the above packages)
and a mailing list
* discuss with releng the infrastructure bits (use the same directory
than releases in cvs?...), find somebody to do the bohdi pushes
* begin to ask for branches in cvs (based on the process discussed
above)
* do a script to generate the list of packages (I can volunteer for that)
Does this looks like a plan acceptable by the Fedora lead?
Opinions, comments?
In this plan, it appears everything is left to the maintainers as to how
long they want to provide updates at which point the end users can't
rely much on the service since some critical packages might turn out to
be not maintained while the rest of them are. If we are going to provide
a extended lifecycle, I believe we need to give users a more definitive
time period.
Here is a counter proposal if you will:
For two releases and a month (approx 13 months), we do the full updates
as we are doing currently. For another say 5 months or till the next
release we do only security fixes and very major bug fixes (as in
crashes all the time sort of bugs). We don't necessarily backport or
guarantee ABI stability at any point of time but we try to reduce the
churn to the minimum possible. Would it be possible to do that for the
entire set of packages? Some metrics on what are marked as security
updates vs others might be useful to determine this.
Rahul
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
