On Feb 9, 2008 1:04 AM, Patrice Dumas <pertusus@xxxxxxx> wrote: > "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). Here's how a read this: "We may close the whole branch at anytime.. be prepared" How do you plan to communicate such a drastic change to the userbase? Right now we make every effort to inform people at release time when the EOL date is for a Fedora release...and even that isn't enough communication. If you can essentially flip a switch and shutdown a branch, how are going to inform people about that? I really think we need clientside tools which can tell people via the repo metadata about the state of packages and the branch itself. Until we get that, I'm going to have a real hard time with something this freeform in terms of timeframe commitments. I understand why its freeform, but I'm really concerned about disclosure to the userbase in a timely manner. And to me timely means, finding a way to tell clients wtf is going on when they attempt to look for updates. What exactly triggers expiring a branch? It would be very easy for someone to just sign up and be the kernel maintainer and do nothing about security bugs and what not. Are the triggerable conditions that translated to 'unmaintained'? And i would have to say that if you flip the switch and expire a branch because of a lack of maintainership, then the branch is dead and doesn't get to come back. You could have a ticking clock in between, but once its dead... its dead. > Opinions, comments? > > If this proposal appears not to be rejected, I'll do a wiki page. I'm really concerned about misleading people about the state of the branch. It's the same concern I have about package orphans and expirations in the main fedora releases just more complicated because the branch could expire as well. Though I think the same implementation solution works here too... repo metadata concerning orphan/expire and ui to support it. And I think you might have to make some sort of additional communication effort concerning security, since you won't have a security team(initially at least) who is track security problems. I'm not sure we can realistically make an open-ended commitment in terms of resources. I think initially you're plan should include a "updates for at most X number of months" so we can estimate resource burn. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
