Proposal: unmaintained.release file in CVS

[Michael Schwendt]

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.