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.] -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
