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

Re: a plan for updates after end of life



On Sun, Feb 10, 2008 at 01:58:05PM -0700, Stephen John Smoogen wrote:

> >From the long discussion list afterwords.. I think there is not enough
> meat on the bones of this to say it can be rejected or accepted. [I am
> speaking as myself a person who needs a cup of coffee]
> 
> 1) Do packages get updated to the latest or are stuck with back patches?

It is the maintainer decision. The rule of thumb is that maintainers
should be conservative, but don't hesitate to update if backports are
too complicated. Or, as I say in the proposal, between fedora and
RHEL/Centos/EPEL.

> 2) What happens for 'core' packages (glibc, kernel, gcc, X, gnome/kde,
> zilla, etc) when the current maintainers (usually Red Hat people) have
> to work on the current stuff and not the back stuff? Who is taking
> them over? What rules do they work with?

Volunteers have to take glibc, kernel, gcc, since they are in the 
mandatory packages list. The amndatory packages list is all the
mandatory and default package in core+base comps groups.
Others are taken by volunteers if they want to.

If a mandatory package isn't maintained for 7 days the whole branch is
discontinued.

> 3) If a dependency package is 'dead' do all the packages depending on
> it go onto the unmaintained list since they can't really be maintained
> either?

Godd question. I'd say same process than in fedora (though I don't know 
how it is done in fedora...).

> 4) Do you have a pool of volunteers who are doing this?

No. But there must be at least one volunteer for each of the mandatory
package before the branch is said to be part of the project.

> 5) Who are they and how many packages are they willing to take?

Not decided in advance.

> 6) What about hardware/software/storage resources? The mirrors and
> diskspace are getting tight and there have been requests to 'purge'
> older stuff? Where do those resources come from?

Fedora infrastructure, as proposed in a previous mailing list thread.

> 7) User communication? This needs to be solved on all fronts, but is
> more important for legacy systems where a user would like to know if
> they are safe or dead. This is probably the easiest to solve though
> with a .eol. repotag :).

A web page lists the packages currently maintained, and those which are
being dropped since less than 7 days. After those 7 days the packages
are considered to be dropped until a new maintainer steps up.

As for repotag, I think this is an issue that would better be discussed
during the discussion with infrastructure.

--
Pat


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