a plan for updates after end of life

[Stephen John Smoogen]

On Feb 9, 2008 3:04 AM, Patrice Dumas <pertusus at free.fr> 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?
>
> If this proposal appears not to be rejected, I'll do a wiki page.
>

>From the long discussion list afterwords.. I think there is not enough
meat on the bones of this to say it can be rejected or accepted. [I am
speaking as myself a person who needs a cup of coffee]

1) Do packages get updated to the latest or are stuck with back patches?
2) What happens for 'core' packages (glibc, kernel, gcc, X, gnome/kde,
zilla, etc) when the current maintainers (usually Red Hat people) have
to work on the current stuff and not the back stuff? Who is taking
them over? What rules do they work with?
3) If a dependency package is 'dead' do all the packages depending on
it go onto the unmaintained list since they can't really be maintained
either?
4) Do you have a pool of volunteers who are doing this?
5) Who are they and how many packages are they willing to take?
6) What about hardware/software/storage resources? The mirrors and
diskspace are getting tight and there have been requests to 'purge'
older stuff? Where do those resources come from?
7) User communication? This needs to be solved on all fronts, but is
more important for legacy systems where a user would like to know if
they are safe or dead. This is probably the easiest to solve though
with a .eol. repotag :).

I don't think this is a bad idea, but it needs to be tighter as a
proposal to get people wanting to jump on board versus having a lot of
places for target shots to be taken at it.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"