On Sat, Feb 09, 2008 at 10:01:42AM -0900, Jeff Spaleta wrote: > 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" It is a bit more complicated. It is 'when we don't have enough maintainer we close the branch'. > 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. Doesn't my proposal explain that? It is plainly stated in what I propose. > If you can essentially flip a switch and shutdown a branch, how are > going to inform people about that? Currently they should read the page of the project. I agree that it is not very comfortable, but I don't think this should be blocking. This is better for the users than no updates anyway, as long as we are very clear about the 'stop as soon as there is not enough maintainers'. > I really think we need clientside tools which can tell people via the > repo metadata about the state of packages and the branch itself. That would be a good idea. > 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. Indeed that would be nice (and nice for orphaned fedora packages too) but I don't think this should be blocking the updates after end of life. > 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'? We trust packagers who sign for a branch to do things, and otherwise to orphan it. Orphaning one of the Core+Base group package (with nobody stepping up instead) triggers the closing of the branch. And if a maintainer doesn't do his job for a branch, it is the same than for Fedora. > 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. That seems right, and what I had in mind. > > 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. Indeed. That would be nice. > 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. That is the work of the packagers. A security team is a bonus, but not really a blocking issue. Worth saying it however. > 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. Can't this be postponed to the time when we discuss the infrastructure stuff? My point of view is that the UAEL project should accept any condition put by those who pay the cost. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
