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

Re: a plan for updates after end of life

On Mon, Feb 11, 2008 at 06:31:29PM -0300, Horst H. von Brand wrote:
> > The number of package is (almost) never a good metric. Indeed some
> > packages are quite hard to maintain (the kernel for example) while
> > others are easy to maintain, either because they are simple. Also some
> > packages may be kept synchronized with a fedora version. The kernel may 
> > not be that hard to maintain, in the end, if the kernel of a stable 
> > fedora release can be used as soon as a security issue is found.
> And how do you propose to measure that? AFAIU, that hasn't been determined
> for Fedora now. And an older package means more work backporting fixes.

I am not the one in search of a metric. I think that no metric make
sense, other than having a packager willing to maintain, and processes
to force a packager to orphan when he doesn't do his job.

> > But, first, we should do that in fedora proper before, and second I
> > don't thinkt hat the result will be much more reliable.
> Right. But as was said, Fedora has its own regulation: It times out at
> EOL. Developers/package maintainers plan for that and move on.

Packages may still be carried over to the next release. And once again
the y are unmaintained, the fact that it is for a given length of time
doesn't make it better.

> What is the use of a Fedora 8 after EOL if any packages with significant
> problems are simply taken from later Fedoras?  

If it make sense, indeed. But not every package suffer from security
bugs. (as a side note, it is not Fedora 8 after EOL, it is UEAL).

> I for one wouldn't trust
> such a chimaera, I'd prefer just taking the later version of the
> distribution in that case. 

Do what you want, nobody forces you to use UAEL.

> The whole point of a distribution for me is that
> it gives me a coherent set of packages that "somebody" has checked that
> they work well together.

The whole point of my proposal wes to have a set of packages that work 
together well by selecting packages based on having a maintainer. 
But maybe I don't understand what you mean.

In any case I have retired the project. I don't want to support
a project where metrics are needed because packagers are not trusted.


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