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

Re: Again: EOL Policy for Fedora Extras



> Because this is not much different from "Fedora Legacy Team"-style
> maintenance. It needs coordination. Essentially, you end up with dedicated
> contributors, who are responsible for a set of packages and who do as much
> package development as is necessary to not break something during upgrades
> and to stay compatible/close with the non-legacy packages for current

I can't see why there should be more coordination in extras with eol fedora
core than with current or devel extras?

> > then, meaning that a packager could be able to communicate that he stops 
> > maintaining a package. It could involve something similar with the orphan 
> > page.
> 
> With the orphans it is simply like "no community interest, no package in
> FE". Mind you, some packages are only in FE because they are build
> requirements. Further, we already do quite some reviews of packages just
> to support eachother. Why should a package, which doesn't find a
> maintainer for several months, be kept in the repository? Do we even know
> whether anybody uses it? We don't have "potentially orphaned packages"
> without reason. It's the only way for a packager to drop a package
> gradually, giving others an early chance to take over package ownership.

I was thinking that something similar could be done for fedora extras 
for eol fedora core versions. I.e. there could be a wiki page where 
maintainers declare that they are not interested in eol fedora core
versions. Potentially if possible and the completely. And the packages could
be then removed from the fe corresponding with fc eol.

> I don't think this would be a good idea, as I see all releases of package
> "foo" as a family of packages, belonging together. So all package
> maintainers of "foo" at least ought to receive copies of all bug reports
> about "foo", regardless of the release version. A vulnerability in an
> old version could affect the latest version and vice versa.

Yep, that's true.

--
Pat


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