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

[Michael Stapelberg]

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 <tincho at 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
Best regards,
Michael