extras maintainence

[Jeff Spaleta]

On 2/10/06, Dennis Gilmore <dennis at ausil.us> wrote:
> how do we do this?  We have two options,
> one) existing package maintainers need to maintain there packages until legacy
> no longer supports a release.  but a stipulation could be made  that once a
> release moves to legacy  the only updates in extras are bugfixes and security
> related.
I do not think this is wise nor do I think this is a workable option.
I think making this a requirement for all package maintainers to have
to track legacy releases will mean less maintainers over time.

> two)  we create an extras legacy team,  who would then take over
> maintainership of all extras packages once a release moves to legacy.
> though if a package maintainer wanted to continue support of his/her packages
> that would be beneficial.

I think this is the only way forward and the most flexible option.
People interested in maintaining things into legacy status should be
the ones responsible for those legacy branches. I'd have no problem
ceding "ownership" of legacy branches to people interested in
maintaining legacy packages. And along these lines, I'm in favor of
package maintainers registering their intent to support or not support
legacy branches upfront when they submit the packages for review. That
we know as early as possible whether or not a package is going to need
to change hands on legacy status, instead of scrambling to determine
if the original maintainer is still interested in legacy branches or
not. Knowing if a package is going to need a legacy maintainer on
package submission, gives the legacy team some time to recruit or
allocate volunteers for those packages if there is a need or it gives
the legacy team enough time to plan a list of orphan/expire subsets of
packages if it becomes clear some packages are unmaintainable with
available resources.


-jef