[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 1:04 AM, Patrice Dumas <pertusus free fr> 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

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


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