Re: reviving Fedora Legacy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux