[pkg-go] Various problems with packages in the group

[Martín Ferrari]

Hi all,

This week I have spent a considerable amount of time tidying up the
group's repositories.

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 [1],
which Michael set up a while ago, and the UDD Maintainer dashboard [2].

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
else prepared.

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.

The list:

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
<pkgname> <description>'


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.

[1] http://pet.debian.net/pkg-go/pet.cgi

[2]
https://udd.debian.org/dmd/?email1=pkg-go-maintainers%40lists.alioth.debian.org

-- 
-- 
Martín Ferrari (Tincho)