Security Response Team / EOL

[Michael Schwendt]

On Sat, 29 Apr 2006 12:28:24 +0200, Patrice Dumas wrote:

> > 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
> 
> You set the requirements for the fedora extras project quite high. So in that
> case we should try to add as little packages as possible.

Argh, I think you misunderstood me, but read on.

> > 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.
> 
> Ok, but it also apply to new packages.

Yes, here I agree. Every unmaintained/orphaned package is bad, regardless
of whether it is in the active or legacy branches. We will need to deal
with orphans in a more radical way. We're given an example in form of
_fire'n'forget packages_, which are packages which pass through the review
process normally, but then are discovered as being orphaned already a few
weeks/months later or during preparation of FC(n+1), because a contributor
and package owner changed his mind or [insert many theoretical reasons
here].

However, what you seem to ignore constantly is the planning reliability.

The planning reliability for those who would maintain the legacy branches
in replacement of original package owners. Assume we [the FE project]
transferred the FE3 branch into maintenance state tomorrow, because the
newly formed security response team had had announced that they wanted to
tackle the problem of keeping FE3 secure as long as FC3 is maintained by
Fedora Legacy. Do we want to keep the gates wide open and permit arbitrary
contributors to fill FE3 with new packages which make FE3 grow and may
need to be fixed by the security team sooner or later? I think we don't
want that. Similarly, we don't want unnecessary upgrades (i.e. version
upgrades with the sole purpose of staying in sync with upstream's release
habits) as they increase the risk (and I've pointed that out before in
older messages) of "regression, dead-end breakage and increased
maintenance requirements" not only for their owner, but also for other
contributors, such as packagers with dependencies, or the security
team. Watch the repoclosure reports! Some of the avoidable breakage that
happens in current branches during version upgrades would likely happen in
legacy branches, too. Whether an individual's packages are trivial to
maintain in multiple branches for a long time, doesn't matter. The big
picture is what matters.

> I think it changes a little the scope
> of the fedora extras project, in my opinion. Not that I think that it is 
> a bad idea, and indeed having such a goal would avoid the 'dumping ground'
> issue. 

Please, let's not loop back again. FE will approach that dumping ground
when we fail to define the life-time of FE branches and a maintenance
model compared with FC.

> But it implies a change in the process of acceptance of new packages.

[cut]

[I cut off the quote here, because it is irrelevant to what I've tried to
say. I do not mean to increase the hurdle and require N>=2 owners for
every new package which enters FE. And I do not mean to require that no
package may ever be orphaned or dropped from the repositories.]