On Sat, Feb 09, 2008 at 12:21:49PM -0900, Jeff Spaleta wrote: > 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? The list of maintained packages would be generated automatically, a package being listed if it has a maintainer for UAEL. I have setup a wiki page showing what it could look like: http://fedoraproject.org/wiki/DraftPageUAEL I have also put a page for the proposal: http://fedoraproject.org/wiki/DraftUAEL > > 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. It is the same for Fedora, where packages can be orphaned. What is important is to be transparent. People can watch the pages in any case since they will be regenerated automatically (I guess there are utilities to do that). > 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. Before EOL packages may be orphaned at any time. > 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. I am sure that there are tools to do the difference between pages and can be used in such cases. > 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. No, we aren't. The process is transparent. > > 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. Then lets fix it in Fedora first, it doesn't make sense to block the project although it is not adressed in fedora itself. > > 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 No, it isn't. A packager can stop maintaining his package before the EOL. > 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 We don't have that in fedora, it is very unfair to point it now! > 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. It is the same in fedora. See the lftp issue that arised lately. > 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. This is exactly the same than in fedora proper. This is not adressed in fedora, there is no need to be stricter here. > 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. Once again this is the same for fedora. The usual processes (MIA, mailing lists, escalation to the proper commitee) would be right, at least until we find something better in fedora. > 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. Ok, this is reflected on the wiki page now. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
