Subject: Re: Maintaining net/pygopherd
To: None <email@example.com>
From: Klaus Heinz <firstname.lastname@example.org>
Date: 06/02/2007 11:41:01
Dave Vollenweider wrote:
> I noticed that the maintainer for this package is set to the address of
> this mailing list. I'm willing to step up and maintain it, but I've
> never done anything like this before. How do I become the maintainter
> and where can I find some documentation on maintaining packages?
> I looked in the Pkgsrc Guide and there's documentation for using and
> making packages, but not really any for maintaining them.
> The two things I want to do right away with pygopherd are update it to
> its current version, which is 2.0.13 (the pkgsrc version is 2.0.9) and
> get it to work with Python 2.4.
> So, how do I get started?
You have already managed the most important aspect: you volunteered to do
Seriously, in order to maintain a package in pkgsrc you should have a
basic understanding of how to build software from source and how to do
that in the context of pkgsrc. For the latter you can read the pkgsrc
guide, as you have done. Any open technical questions about maintenance
of a package can always be asked on tech-pkg.
Joining the pkgsrc-wip project (see <http://pkgsrc-wip.sourceforge.net/>)
can also help you. If you want to have the bleeding edge of the
software, which may not be suitable for pkgsrc itself due to stability
reasons, pkgsrc-wip is the ideal place to work on the package.
Using the software, at least occasionally, is very helpful in case there
are bugs. If those bugs are reported to the GNATS tracking system
(pkgsrc-bugs), they will be assigned to you.
You should try to determine whether the bug is related to pkgsrc
or originates in the software itself. Bugs related to pkgsrc should be
fixed, with help from the community if necessary.
For a bug not caused by pkgsrc you will probably contact the original
authors ("upstream") to see whether this is a known defect.
If your are able to fix such problems, so much the better, but you are
certainly _not required_ to do that, which may be really hard sometimes.
If building the software in pkgsrc needs any patches they should be fed
back upstream for integration into the next official release, provided
they are general enough to be valuable to them (ie, not directly caused
by some feature of pkgsrc). In my experience, authors will accept
patches if they are created in a way that impacts builds on non-pkgsrc
systems either not at all or in a very minor way.
Making the software authors aware of the package being available in
pkgsrc is also a nice way of advertising pkgsrc :-).
You mentioned two points you want to do right away:
- Updating the software to the current version
The update is a task expected of the maintainer. The package in pkgsrc
should be a current and stable version of the software, if at all
possible for all the supported platforms.
- Getting it to work with Python 2.4
If the software itself has problems with Python 2.4 then this is
something you _can_ do if you want to, but it is not something I would
expect of a maintainer.
If the problem is somehow related to pkgsrc it should be fixed by the
There is one negative aspect of being the maintainer: Be prepared that
the e-mail address you provide for the MAINTAINER field will be widely
known and probably abused by spammers.