Maintainer Responsibilities and Arrogance

When I was recently combing through new packages in aptitude, I came across a package named svn-workbench. Since I am a fan of Subversion the name got me interested. The package’s short description (“A Workbench for Subversion “) didn’t help much. So I went to the long description, which I will quote here in full:

pysvn-workbench is a workbench for subversion, written in the Python language.

Not very helpful either. So I decided to write a bug report to ask the maintainer to improve the full description to be actually useful. When I looked at the existing bug reports for svn-workbench, I saw that somebody else had already posted this problem as bug 299175.

Please take a moment to read the bug report. The original reporter pointed out clearly what the problem with the current description is. This was backed by another user who also pointed out that the Developer’s Reference recommends to include the upstream home page in the long description.

The maintainer’s response to the long description problem was simply: “send a patch”. Sorry, as a maintainer you can’t require users of your package to do your work, especially not if it’s a fundamental task as this. If you can’t even be bothered to write a short and concise description of your package, how can we assume that the rest of the package is not in the same miserable state? What does a lapidary comment such as this tell our users? In this case the seconds reporter was also Debian developer, but what if a normal user comes across this bug report? Also, why is the submitter expected to write a description of a software he doesn’t even know? If he knew he surely wouldn’t ask what the software does, would he?

Another point is the maintainer’s answer to the request to put the homepage in the description: “no, there’s one file where it belongs: debian/copyright. Adding it to several places is just a maintainance burden.” While I agree that the Developer’s Reference is not the Policy, it should not be lightly ignored. We want to have a consistent system, where users know what to expect. Also, normally there is a reason for the recommendations in the Developer’s Reference. In this case the long description should include the home page address so that users can view more information about the package before installing it. To refuse to include it in the long description for the increased “maintainance[sic!] burden” is just a weak excuse.

Our users have earned a better treatment, doko!

Templating and “that card”

From today’s Ask the Judge:

Q: At the end of my turn, if my Shirei, Shizo’s Caretaker is still in play, a land that went to my graveyard from play as a 1/1 creature due to Living Plane does not come back into play, does it? It says “creature card” on Shirei, which makes me suspect.

A: This land card will still be returned to play. Rule 404.4c says: ‘A delayed triggered ability that refers to a particular object still affects it even if the object changes characteristics.’ When Shirei’s ability says to return that creature card, it means that you return to play that card regardless of card type it is. This happens because that triggered ability that returns that card to play is a delayed triggered ability.

Here is the current oracle text of Shirei:

Whenever a creature with power 1 or less is put into your graveyard from play, you may return that creature card to play under your control at end of turn if Shirei, Shizo’s Caretaker is still in play.

I think that the question shows a problem with current templating. As the submitter of the question points out, the term “creature card” leads you to assume that only creature cards can be returned to play. While the rules make it clear that this is not the case, as Chris points out, it’s still a violation of the rule that cards should be as clear as possible. In my opinion “that card” would be more concise and not in any way less clear to newer players.

I’m a little undecided what to do about permanents, though. See for example Through the Breach:

Put a creature card from your hand into play. That creature has haste. Sacrifice that creature at end of turn.

Say you put a creature card into play with Through the Breach. You turn the creature into an Enchantment using Soul Sculptor. You will have to sacrifice the Enchantment, although it isn’t a creature anymore because of rule 404.4c. In this case it is not a good idea to have the oracle text read: “… Sacrifice that permanent at end of turn.” The problem here is for newer players to understand the term “permanent”.

I’m back to Debian

So, I finally found time to do Debian work again after a far too long abstinence. Unfortunately I didn’t manage to hand over my Debian stuff gracefully, but fortunately there were people having an eye on them. Jonas Smedegaard had an eye on the Netatalk package and released a security fix for it. The GNOME team, headed by Sebastien Bacher was taking care of ORBit.

The first thing I did was to hotfix some of my packages. Get out a new ORBit release and release a first version of Netatalk 2, a much requested upgrade. This new Netatalk version has many improvements and it’s good to finally have it in Debian, though there is still much work to do. Soon after releasing netatalk-2.0.2-1 I got a bug report concerning CJK support. This is something that needs to go in ASAP, but currently I don’t have the knowledge to review and apply the referenced patch. I’m out of the loop of Netatalk programming as well.

So, let’s have a look at my packages:

gnome-chess
This is currently seriously broken and badly needs a port to GNOME 2. AFAIR there is some unfinished work in GNOME CVS, which I have to look into. But at the moment this package is not high priority.
gnome-pim
Another GNOME 1 package. Before my hiatus I started to rewrite this package for GNOME 2 and there were grand plans for it. These plans are still there and I have continued the port. I hope to have a working pre-release of the new GNOME 2 package out soon, though there’s still lot of work to do, before this can be uploaded to Debian unstable.
gtk-doc
While I’m still listed as maintainer, I handed this package over to Loic Minier a few weeks back, and it seems to be in good hands.
libidl
Base package for ORBit 2. Just updated from 0.8.3-1 to 0.8.5-1,
though the upstream changes were only very minor. No open bugs, this package seems to do fine.
linc
Base package for ORBit 1. Obsolete, see below.
netatalk
As I wrote above I just upgrade this to Netatalk 2.0. While this
was quite a major change (I got rid of the unnecessary netatalk-dev package in the process), I don’t forsee any major problems. The upstream package is quite well tested at this point and included in many other distributions. But you never know …
orbit
ORBit 1 is an old, obsolete package from GNOME 1 days. It has a
few open bugs, but probably nothing that is worth fixing. Instead my energies should be focussed on porting all stuff that still depends on it over to GNOME 2 (see also above).
orbit2
Just upgraded to upstream version 2.12.2. This is a fairly stable,
slowly developed piece of software. Only one open bug in the Debian BTS and that is a wishlist item. This package is also doing fine and needs minimal maintenance.

Now I have to get up to snuff at what’s up with Debian. I completely missed the DPL elections and so I will not vote, since I have not enough information about what’s currently going on. Then there was the interesting proposal about dropping stable support for less-used architectures after sarge. Oh yes, speaking about sarge. It’s still not released. But then I didn’t have high hopes that it would be …