Stephen Gran <[EMAIL PROTECTED]> writes: > What I (and it seems, others) would like to see is: > 3) some other method to upgrade software that has to change rapidly to > meet new classes of threats, even though these threats may not affect > the machine running the software itself. This category seems to me > to be composed of A/V scanners, anti-spam suites, and IDS-type software. > I may be missing some, and I'm sure someone will chime in with it.
What we want with this is a way that is *stable*. If you can't promise me stability, then I don't want it (or I want it at arm's length). The backport work is part of the beast here, and "where the archive lands" or "which team does the work" is only a red-herring. That's why I kept saying "we have a procedure"--because the problem is not the absence of an archive, nor the absence of a team; the problem is an agreed maintenance strategy. I would like to see a concrete proposal that is something more than "we need a place where we can make arbitrary changes to certain packages in stable." In particular, I would like to see something like what we have for the existing security maintenance scheme: a policy that requires backporting and does not simply wholesale include new upstream versions complete with all the new features--and bugs--that they may have. Thomas
