On Sun, 27 Aug 2006 23:06:13 -0500, Jason L Tibbitts III wrote: > One issue that has come up repeatedly is deciding when someone should > step up to do work on a package in the absence of maintainer action. > Some (perhaps most) maintainers don't want to maintain their packages > for Fedora releases that have been passed to Legacy, yet the various > people who may still be interested in these packages (especially the > security team) have no way to know if the maintainer is still > maintaining a release or not. > > So I propose that we indicate this in some manner. In the absence of > a package database which will of course give us that ability, I > propose simply adding a file named "unmaintained.release" to CVS in > the same manner as the "needs.rebuild" file. > > Alternately, we can invert the expectations and require that packagers > add a "maintained.release" file to CVS to indicate that old releases > are still maintained. I think that this is less optimal than > specifically indicating that a release is unmaintained, but it has the > property of releases automatically being unmaintained if there is no > maintainer action which may better meet expectations. We could also > get this behavior by automatically adding the "unmaintained.release" > file when a release goes to Legacy. > > - J< Feasible, but half-hearted unless there is some strict policy on who may touch such "unmaintained" packages. In would not be a good idea if arbitrary contributors updated and upgraded arbitrary packages without talking to eachother and without filling the role of a "missing owner", also in bugzilla. owners.list can't store different package owners for different branches. And one pitfall Fedora Legacy has run into several times is shipping updates that were newer than what was in current releases of Core, even if just due to a newer %release, and worse when it's a newer %version. Broken upgrade paths and uncoordinated version upgrades are painful, particularly when a new version introduces API/ABI changes, is missing patches, or is not considered ready by the primary package owner or maintainers of dependencies. Sure, it's an education thing that co-maintainers or multiple maintainers for different branches monitor eachother, talk to eachother and also handle bugzilla tickets. But that needs guidelines or a policy. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
