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

[Martín Ferrari]

Hi,

On 13/09/15 18:28, Michael Stapelberg wrote:
> 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.

Ah, possibly many of these issues I found have an in dh-make-golang..
Honestly, I haven't tried it yet :-)

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

I does imply that, yes. I guess this (having upstream history) is not as
important as the other points, but I would argue that in many situations
it can help a lot your work (for example, if you want to find when and
why something changed in the code, or why a patch stopped applying), and
it does not really get in the way. You can usually just ignore upstream,
and merge only when starting a new release. I guess you could also
rebase and pack all those changes into a single commit, but then the
whole point of tracking upstream is lost.

On the other hand, not having the upstream source at all (I found one
package like that today) is bothersome, and I don't see any good reason
for that..

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

Possibly. I have adopted a set of git config options that I took from a
really detailed description of a git workflow (I don't remember the link):

# Assuming the debian remote is called 'debian':

git config --add remote.debian.push 'refs/tags/debian/*'
git config --add remote.debian.push 'refs/tags/upstream/*'
git config --add remote.debian.push 'refs/heads/debian/*'
git config --add remote.debian.push 'refs/heads/pristine-tar'
git config --add remote.debian.fetch 'refs/tags/*:refs/tags/*'

This will always push debian-related tags and branches, and avoid
pushing other tags (like upstream tags). It is very convenient.

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

I have not noticed that was being discussed. But you can assume my +1 on
that PR, obviously :)


-- 
Martín Ferrari (Tincho)