Re: New 'maint' facet for Debtags
On Mon, Sep 17, 2007 at 01:50:46PM +0200, Enrico Zini wrote:
> In the same way we can have an autogenerated 'maint' facet with tags
> documenting the status of the package maintenance.
>
> Below is an example vocabulary for it, with annotations on how to
> autogenerate the tag information. I'd like to run some discussion on it
> for a week or so, then proceed to implementation.
>
> Tag: maint::orphaned
> Description: Orphaned
> There is no maintainer for this package. Maintenance is done by the Debian QA
> Team.
> (it can be autogenerated by looking if debian-qa is in the Maintainer field)
>
> Tag: maint::rfa
> Description: Adoption requested
> The maintainer is still maintaning the package, but has requestes for someone
> else to take over its maintenance.
> (it can be autogenerated by scanning open WNPP bugs)
maint::rfh for RFH bugs should be a trivial extension of this concept.
The interesting question would be how to handle ITA bugs. These packages
can either be owned by debian-qa (in this case we already have
maint::orphaned) or they can be owned by the former maintainer (in case
of a fast O -> ITA or in case the ITA is a former RFA).
> Tag: maint::mia
> Description: Maintainer unreachable
> The maintainer for this package is currently unreachable.
> (mia-query on merkel shows all sorts of data, but I need to see how it
> can be turned in a tag. It has been suggested that if a maintainer is
> MIA, the package should just be orphaned, so this tag would be of no
> use, and I tend to agree)
I agree. This tag makes no sense.
> Tag: maint::old-rc-bugs
> Description: Old unfixed RC bugs
> The package has unfixed RC bugs older than 3 months.
> (it can be autogenerated by scanning the BTS)
I'm a bit unsure about that one. Having old RC bugs does say nothing
about a package without actually reading at least the titles of the bugs
in question (think non-free documentation/RFCs vs. "should not go to
stable because of instable API/ABI/..." vs. "this is crap, should be
removed" vs. "FTBFS in unstable because <random other library> is
fucked up"). I see no real information value here.
What I would like to see would be a maint:obsolete tag. Can be added
to packages that are already removed from unstable and only supported
in stable or for packages that are only maintained in unstable for
external reasons (like dependencies). Think GNOME 1/GTK 1.2. This would
generally be the debtags equivalent to the oldlibs section.
For the "removed from unstable" case this would need to be filtered
manually probably, since it shouldn't be assigned to libraries in stable
just because they had a SONAME change in unstable...
For packages that aren't removed from unstable this could be a
maintainer field.
> Tag: maint::fringe
> Description: Fringe package (FIXME)
> The maintainer declared this to be a fringe package.
> .
> (TODO: define what this practically means)
> .
> (from IRC) more users == greater level of peer review and peer support?
> (maintainers can enter this information in debian/control and I can scan it using Mole)
>
> Tag: maint::unmaintained-upstream
> Description: Unmaintained upstream
> The package is not maintained anymore by its upstream developers.
> .
> Debian still carries on basic maintenance, but no new upstream versions of the
> package are to be expected.
> (maintainers can enter this information in debian/control and I can scan it using Mole)
Didn't someone mention in the Debconf session something along the lines
of maint::only-upstream? In the sense of "I'm the Debian maintainer and I
package new upstream versions and forward bugs, but I don't understand
the code [because it is too complex, because I don't speak the
programming language] and will/can not fix any bugs in it myself".
That should probably correlate to a open RFH/RFA bug but there might be
reasons it doesn't.
This would be a maintainer field.
Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/
Reply to: