[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: a plan for updates after end of life

On Feb 9, 2008 11:33 AM, Patrice Dumas <pertusus free fr> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]