As a meta-point: I think we should change dh-make-golang to do the right thing once we agree on these suggestions. At least the first point you mention (repository creation) is already properly handled, i.e. dh-make-golang gives you a setup-repository command to run.
On Sun, Sep 13, 2015 at 2:54 PM, Martín Ferrari <tin...@debian.org> wrote: > 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>' Agreed, I think this is a no-brainer. > > > 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. Does this imply having a git history such as displayed in https://anonscm.debian.org/cgit/pkg-go/packages/golang-uuid.git/log/? I find that super-annoying for packages with active upstream repositories, because I’m almost never interested in an individual upstream commit, but rather at high-level changes that directly correspond to uploads to Debian. I.e., I prefer seeing a single “Imported upstream snapshot X” commit over seeing hundreds of individual upstream commits. > > > 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. Agreed. I think whenever this happens, it’s just a mistake such as forgetting to push the tag or something similar. > > > 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. See also https://github.com/Debian/dh-make-golang/pull/16 — I wanted to change the team policy document on that before accepting the PR, but I think we all agree by now. > > [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) > > _______________________________________________ > Pkg-go-maintainers mailing list > Pkg-go-maintainers@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers -- Best regards, Michael _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers