Crossing debtags and popcon

[Justin B Rye]

Andrea Bolognani wrote:
>>> When the archive coverage will be complete, this won't be a problem anymore:
>>
>> Presumably this will happen some time after we run out of new
>> software to add to the archive!
> 
> Not if we force any new package to be tagged.
> 
> Explain the need to tag every package in the New Maintainer's Guide. Add a
> "should" in the Developer's Reference. Provide extensive documentation on how
> to correctly tag a package, then add a lintian/linda check to make sure most
> mentors won't sponsor untagged packages, or at least warn the maintainer.

In principle these are objectives we should be working towards, but
pardon me if I don't hold my breath waiting for them to be realised.

>>> the tags for the version in testing of a package will be correct and, even
>>> if the version in unstable will have different tags, this would mean only
>>> that some of the functionalities of the package are different, not that the
>>> newer tags are better.
>>
>> Remember my example.  The foo-media-player in my Packages file is
>> the Stable version, a role::dummy package that pulls in a -gui and
>> -common packages; the package of that name in Sid is role::program
>> and works-with-format::{all sorts of things that the Stable tag
>> vocabulary has never heard of}.  In that situation, the newer tags
>> are _worse_ for me.  Tag-archives outside the Packages file need
>> release-name stamps.
> 
> Sorry, I don't really get this.
> 
> If you use Sarge,

(Actually, my scenario was set after the Etch release.  Sarge
debtags doesn't support online archives anyway.)

> then role::dummy is the right tag. If you use Sid, then the
> right tags are role::program and works-with-format::*.
> 
> Please correct me if I am wrong.

The hard part is getting the right tags in the Packages file; if we
could take those for granted, supplementary archives wouldn't be an
issue.  For me as a Stable user, role::dummy would be right; but if
the tags available in the Packages database mistakenly say that
foo-media-player is role::special:todo, I'm stuck with a choice
between that and the equally-wrong-for-Stable tags on alioth.

>> Improved (and better-automated) coverage in the Packages file would
>> be good; but I'm against having it entirely replace the online
>> databases, because that would make things worse for my local users
>> in two regards:
>> * if the only way to correct a tag is to provide a well-formatted
>> 	patch to the source tree, that's a barrier against
>> 	contributions (especially from non-developers).
> 
> Or to file a bug against the package having wrong tags.

That _is_ filing a bug.  Wishlist bugs without a patch are much more
likely to be ignored.

> Non-developers already do this for all other kinds of bugs -- and yes, I
> consider wrong tags to be a bug in the package. At least a wishlist one.

It's a barrier against contributions.  A tags-patch list of 100
packages in need of the new works-with-format::mp4 tag is an
enjoyable task for a teabreak, with near-immediate useful results;
100 wishlist bugreports to MIA maintainers is a wasted weekend.
 
>> * if there are no online archives, the only way to get corrected
>> 	tags is via new package versions - and for Stable users,
>> 	that means waiting years.  By which time foo-media-player
>> 	may be role::dummy again.
> 
> You should get the tags related to the version of the package you have
> currently installed.
> 
> If I have Sarge's foo-media-player installed, I want it to be tagged
> role::dummy. I don't want it to appear in any search I perform against
> works-with-format::whatever. That would be just wrong.

You're assuming perfect tagging.  We don't have that, and I would be
prepared to place a sizeable bet that we never will.

>> Of course (going back to my original point) if the online archives
>> are all tracking Sid, they're no use to Stable users.  However, if
>> there was a separate online tag-archive for each release, it would
>> be the Stable users who would need alioth the most, because they
>> can't get tag corrections into their Packages file.
> 
> I think the main point here is that we have different ideas on how packages
> should be tagged.
> 
> My point is that having the right tags for a package is maintainer's duty,
> just like it's maintainer's duty to make sure the package works correctly and
> bugs are fixed.
>
> This of course would require some changes at the dpkg level, and tons of good
> documentation.
> 
> The very same people who are volunteering their time to tag packages would do
> exactly the same, but by filing bug reports instead of editing the tag
> database directly.
> 
> I know it is a very broad task, and it will require a lot of work, but I think
> we can do this in time for lenny.

You are an optimist.  I'm not even going to start hoping for this
until we've had another round of fixes to the organisation of the
vocabulary - your BTS-driven proposal would make it extremely
arduous to modify the vocabulary and then re-tag the archive
appropriately.  Even if we never plan to change the vocabulary
again, that means we need to change it at least one more time to
eliminate the ::TODO tags!

If we can get the vocabulary frozen by Lenny (and I'm not sure we
should, let alone could), then we can start debating the necessity
for the online tag-submission system in Lenny+n; but in the
meantime, there will be Stable users whose interests deserve some
consideration.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)