[pkg-go] Various problems with packages in the group
tincho at debian.org
Sun Sep 13 12:54:43 UTC 2015
This week I have spent a considerable amount of time tidying up the
This was motivated initially because I wanted to work on pending bugs,
uploads, etc. And a great tool to keep track of pending work is PET ,
which Michael set up a while ago, and the UDD Maintainer dashboard .
For these tools to be useful, a few conventions need to be followed.
These conventions are usually very useful for team maintenance, as there
is much less guessing involved when working with a package that somebody
I've also found issues that hamper team work, even if they are not
problematic for PET/UDD.
So, here is a list of problems, and what I consider
solutions/best-practices for them. I believe them to be more or less
non-controversial across packaging teams, and I believe it would help a
lot the team if we all use them.
I learnt most of these guidelines in the pkg-perl group. Without a lot
of person-power, they maintain over 3000 packages, with an impressible
attention to detail, and they make it very easy for new contributors to
join the group. I really trust what that group considers good practices :-)
Comments and criticisms welcomed.
P: Many repositories had permission problems and missing hooks (which in
turn means no KGB notifications nor PET updates), because they were
created manually instead of using the setup-repository script. The
permissions problem is particularly bothersome as it makes it impossible
for anybody else to work on the package.
S: Always create repositories running '/git/pkg-go/setup-repository
P: Packages missing upstream source or history. Although many groups
tend not to include source, it is good to have consistency. I would
argue that not having the source makes your life as a maintainer a lot
more difficult, and with most people using git these days, having
upstream's history can be a life saver.
S: Instead of just importing debian/, start by adding upstream as a
remote, and 'git checkout -b upstream' based on the tag you want to package.
P: Missing tags for releases. This confuses PET and anybody working on
your package: without the tag, you can never be sure what is the commit
that matches what was uploaded.
S: Always use debcommit -r, which will create the tag automatically,
when the package is about to be uploaded.
P: Having unfinished packages with 'upstream' distribution in
debian/changelog, instead of 'UNRELEASED'. This is a convention
originating in dch: when you start working on a new version of a
package, dch will set the distribution to 'UNRELEASED', so there is no
confusion with already-uploaded versions. This is also use by PET to
differentiate work-in-progress packages, with packages that are ready to
upload or already uploaded.
S: Use dch to start a new version, and dch -r to mark it as finished and
ready for upload/sponsoring. Packages that are marked like this but not
tagged are usually candidates for sponsored uploads.
Martín Ferrari (Tincho)
More information about the Pkg-go-maintainers