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
