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

Re: Security Response Team / EOL



On Fri, 28 Apr 2006 16:33:35 +0200, Patrice Dumas wrote:

> > build infrastructure -- the whole point of maintenance mode is to reduce 
> > the amount of infrastructure work needed to keep Fedora going to something 
> > manageable with the amount of resources Fedora has.
> 
> Not doing anything special for maintenance branches is the better way to
> reduce the amount of infrastructure work needed to keep Fedora going.
> I don't think the load on the buildsys is relevant here, at least it is
> not my impression. For the disk space and bandwidth I don't know.

The resource requirements would grow, because the legacy repository would
still grow, and its total maintenance requirements would increase. And who
knows how long after the corresponding FC release entered legacy mode a FE
packager might start adding new packages to the branch?

I don't care whether FE packagers backport security fixes or whether they
fix them with version upgrades. Sometimes backports would not be feasible
without much effort. And sometimes a version upgrade would be a big
version jump, when upstream uses a discovered defect as an opportunity to
push out a new major release. In that case, version upgrades in legacy
branches could not be avoided even if they introduce new risks.

But adding entirely NEW packages to FE when FC is locked in legacy
maintenance mode, is an inconsistency I feel that is bad. Not only does it
create an inconsistency, it creates chaos in some areas as users don't
know what they can expect (think bug reports "version 1.1.2 is out, please
upgrade"). Reading again and again that users should rely on packagers to
do the right thing, this enters the old loop of asking: What do we aim at
anyway? It would be a promise that we believe the packagers do the right
thing. It's not individuals who promise something, it's the entire FE
project which makes the promise. And when we do that, users should also be
able to rely on the project to maintain the full set of packages when a
packager doesn't respond [in time] or when a package is officially
orphaned. This brings us back to a security response team of
volunteers. It simply doesn't work to let some packagers extend a legacy
branch with new packages when that might result in increased maintenance
requirements for the rest of the project either immediately or some time
later.


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