On Feb 9, 2008 11:33 AM, Patrice Dumas <pertusus@xxxxxxx> wrote: > > 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. I'm not sure it does, and if it does then I'm too dumb to see it. If I'm going to be using this branch... where do i go to know what the state of branch health is? How do I know that a core piece has fallen out of maintainership? > 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 don't agree that is better. What i think is better is timely notification of state of branches and packages so users and admins can take action as they see fit to either help by participating in the maintainence burden, or choosing to uninstall the package based on the knowledge that its out of maintainence, or making an informed choice to live with the risks. Right now users who continue to use Fedora beyond stated EOL are making an informed choice to do so. In fact we tell them early enough about the timeframe that its a planned informed choice. Its not the choice I would make... but it is an informed choice and we aren't surprising them. Extending the lifetime of things in a freeform way only increases the risk that a package will go unmaintained without the users/admins knowing that it is. Unless we implement timely notification on the client we are not balancing that increased risk with increased notification. We are making it harder for people to make informed choices. And i think that balance is of ultimate importance, so that admins/users can make informed choices about what to do when packages and whole branches go EOL. > 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. I'm very concerned about this issue. > We trust packagers who sign for a branch to do things, and otherwise to > orphan it. Trust... but verify. Right now the trust we extended to maintainers is circumscribed by a hard and definite EOL timeframe. I think its inappropriate to have the timeline of a branch solely dependent on trust...unless you have process to verify that people are doing the necessary work required to keep the branch alive. It'd be really damn easy for people to just sign up for Core packages and do absolutely nothing to fix issues in them, just to keep the branch alive... because you have created a conflict of interest. The people using the branch, don't want to see the branch die, and as a result they'll claim maintainership on core packages just to keep things going. Unless you can verify that things are getting done. If for example the kernel has an exposed security flaw for X number of months without a fix...regardless of whether someone is officially listed as a maintainer.. the branch needs to die. You are delibrately tieing 'maintainership' to the branch continuation.. and if you do that.. you need to be very honest about what maintainership means... or else we'll have a branch linger for years without actual effort going into core packages. > > 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. Just making sure you are aware, that any proposal in this space will be subject to a resource constraint... maybe a pretty severe one initially. Just don't make any promises about the maximum length of time. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
