reviving Fedora Legacy
Chuck Anderson
cra at WPI.EDU
Sun Oct 12 15:47:55 UTC 2008
On Sun, Oct 12, 2008 at 02:33:41PM +0200, Patrice Dumas wrote:
> On Sun, Oct 12, 2008 at 01:34:15PM +0200, shmuel siegel wrote:
> > Seems to me that you have the beginning of a plan. There needs to be an
> > individual with the responsibility to create a full-blown proposal. He
>
> https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598.html
>
> At some point there was a page in the wiki, I can't find it anymore.
I just re-read the entire thread (its not that huge):
http://fedoraproject.org/wiki/DraftPageUAEL
http://fedoraproject.org/wiki/DraftUAEL
It sees that the main objections were/are:
1. Without some sort of statement on lifetime, users would be left
high and dry at any instant in time that the branch could be declared
"dead" after 7 days without a maintainer for one of the @core @base
packages.
It was proposed to have a client-side UI to inform users of the
viability/end-of-life/status of a branch. I believe PackageKit could
be used to do this now. It has been discussed for regular Fedora EOL
that a notification be sent via package metadata, possibly offering
the user an upgrade path. This upgrade path could be to the next
Fedora via Pre-Upgrade, or to UAEL via changing the yum repo
locations. Likewise, at the end of UAEL life, similar warnings could
be put out in advance of the EOL.
Also the bit about "if one of these packages isn't maintained anymore,
the whole branch is retired after 1 week." won't really work with the
above. At the very least, give 3-4 weeks for a new maintainer to be
found, on par with the existing Fedora policies.
My personal opinion is to start with a very limited extension of
lifespan. E.g. when F-8 goes EOL one month after F-10, UAEL would
extend F-8 to one month after F-11 is released, giving an additional
6-7 months of lifespan to F-8. This would limit the amount of UAEL
work to one distro release at a time and would solve one set of
user/sysadmin problems, which is that by the time F-N stabalizes and
slows down enough to upgrade to it (in my experience that is around
the time F-N+1 comes out), there is only 6-7 months left before it
goes EOL. This proposal would extend that remainder to 12-13 months.
At least then they could follow an annual upgrade cycle. If they need
more than a year, perhaps RHEL/CentOS is the right choice for them.
I think it is important that no matter what timeframe is decided, UAEL
maintainers as a group must agree to stick to it, just like Fedora
maintainers now are expected to stick to supporting their packages for
the lifespan of F-N and F-N-1.
2. Jeff Spaleta wanted metrics and verification to be sure the UAEL
maintainers were actually doing their job and maintaining the packages
they said they would, and metrics to be sure no one maintainer took on
too large of a load to prevent from getting burned out.
I think it is unrealistic to require more oversight for UAEL than
there is for regular Fedora maintainers. Trust that they will do the
work. If they don't, follow the same policies and procedures we have
to deal with that in Fedora today.
3. On the matter of infrastructure. The UAEL proposal suggested that
we reuse the existing Fedora infrastructure and just let the F-N
branches live on, or create new branches in CVS for UAEL-N so as to
allow UAEL contributors to concentrate on packaging, rather than
setting up new infrastructure.
How would this affect the existing Fedora Infrastructure maintainers?
Would this require much more committment and work from them? Or is
this just limited to finding someone to sign packages? Are they okay
with that? By limiting the lifespan to 7 months or so, this also
limits the expectations we have from Fedora Infrastructure.
4. On ABI/API stability. Fedora has no guarantee for ABI/API
stability. Neither would UAEL. Maintainers could choose to upgrade,
backport, or "steal" from newer Fedora/RHEL/CentOS as they see fit, to
the same extent that Fedora package maintainers can and do today. I
don't see UAEL having any more guarantees than Fedora does in this
regard. Again, if you want more than this, then perhaps RHEL/CentOS
is the right choice for you.
5. On security. How does the Fedora Security Team work now? It seems
to be a pretty opaque group, i.e. not transparent to the rest of the
community. Without knowing how this part of Fedora works, it is hard
to formulate a plan for UAEL. At worst, UAEL could be reactive to
other security announcements and update releases, like how Fedora
Legacy used to work. At best, there would be some cooperation between
the Fedora Security Team and UAEL.
More information about the fedora-devel-list
mailing list