[pkg-go] Bug#798725: Bug#798725: golang-github-vbatts-tar-split: FTBFS: B-D favors nonexistent packages over real ones
Michael Stapelberg writes: > I think the better fix is to actually upload > golang-github-codegangsta-cli-dev and > golang-github-sirupsen-logrus-dev. Go for it (no pun intended), but bear in mind that this issue will persist until the uploads clear NEW. Meanwhile, rawdns's build dependency on golang-github-miekg-dns-dev | golang-dns-dev is similarly problematic. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] RFS: golang-github-bitly-simplejson
On 13 September 2015 at 12:00, Tianon Gravi wrote: > To be more clear: I'm working on renaming the source package now, but > would appreciate if you'd clarify the reasoning for the license > mismatch. :) Same set of comments for "golang-revel" (which is a dep of bugsnag-go). ;) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] RFS: golang-github-bitly-simplejson
On 13 September 2015 at 11:58, Tianon Gravi wrote: > It looks like bugsnag-go has the same problem (and ought to have a > source package rename since the initial version isn't even uploaded > yet, so it's easier to rename now than later). :) To be more clear: I'm working on renaming the source package now, but would appreciate if you'd clarify the reasoning for the license mismatch. :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] RFS: golang-github-bitly-simplejson
On 13 September 2015 at 10:03, Michael Stapelberg wrote: > • debian/* is licensed under GPL-2+, but upstream is MIT. Consider > using the same license to avoid headaches when shipping patches. It looks like bugsnag-go has the same problem (and ought to have a source package rename since the initial version isn't even uploaded yet, so it's easier to rename now than later). :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#798649: Bug#798649: golang-golang-x-net-dev: new upstream release?
On 13/09/15 20:18, Michael Stapelberg wrote: > Tincho, why did you modify the upstream branch instead of shipping a > patch in debian/patches? I thought the upstream branch should contain > _unmodified_ upstream contents. You're right, that was a mistake. Since they don't produce releases, I patched upstream and made an orig.tar.gz from that, but I should have made a Debian patch instead. > Also, could you take a stab at this bug please and package a new snapshot? Sure, I will look into it later today or tomorrow. -- 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
[pkg-go] Bug#798649: Bug#798649: golang-golang-x-net-dev: new upstream release?
I tried looking into this, but it’s not trivial. https://github.com/golang/go/issues/10904 required a revert of some commits (see https://anonscm.debian.org/cgit/pkg-go/packages/golang-go.net.git/commit/?h=upstream&id=316f04ccdf09acb3d65aff39abb11ef287859815), but is still unfixed. I think we’d need to either have go1.5 or patch upstream again, just with a newer snapshot. Tincho, why did you modify the upstream branch instead of shipping a patch in debian/patches? I thought the upstream branch should contain _unmodified_ upstream contents. Also, could you take a stab at this bug please and package a new snapshot? On Fri, Sep 11, 2015 at 3:00 PM, Dmitry Smirnov wrote: > Source: golang-golang-x-net-dev > Version: 0.0+git20150226.3d87fd6-3 > Severity: wishlist > > I'm packaging "google.golang.org/grpc" which fails on missing files in > "golang.org/x/net/trace" -- I think the latter was introduced upstream after > 2015-02-26 hence I'm asking for new upstream release (or snapshot) of > "golang-golang-x-net-dev" please. > > -- > All the best, > Dmitry Smirnov > GPG key : 4096R/53968D1B > > ___ > 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
Re: [pkg-go] RFS: golang-github-bitly-simplejson
On 13 September 2015 at 10:07, Paul Tagliamonte wrote: > To -alpha or ~alpha? Also, upstream has nice version tags[1], so why are we packaging a snapshot instead of using debian/watch and a direct release version? Is there a package that needs newer commits? If so, have we asked upstream to tag a new version? :) [1]: https://github.com/bitly/go-simplejson/releases ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] RFS: golang-github-bitly-simplejson
To -alpha or ~alpha? On Sep 13, 2015 1:03 PM, "Michael Stapelberg" wrote: > • debian/* is licensed under GPL-2+, but upstream is MIT. Consider > using the same license to avoid headaches when shipping patches. > > • The package does not build with gbp: > > /tmp/golang-github-bitly-go-simplejson master $ gbp buildpackage > --git-builder='sbuild -v -As --dist=unstable' > gbp:error: upstream/0.5.0-alpha_git20150401 is not a valid treeish > > On Fri, Sep 11, 2015 at 1:30 AM, Potter, Tim (Cloud Services) > wrote: > > On 9 Sep 2015, at 2:07 pm, Paul Tagliamonte wrote: > >> > >> On Wed, Sep 09, 2015 at 03:46:41AM +, Potter, Tim (Cloud Services) > wrote: > >>> On 9 Sep 2015, at 1:34 pm, Paul Tagliamonte > wrote: > > On Wed, Sep 09, 2015 at 03:28:59AM +, Potter, Tim (Cloud > Services) wrote: > > Hi everyone. This package is required for bugsnag and I’ve just > finished renaming > > it and testing against the new naming policy. > > > > Could someone please review and upload? > > Ah, your RFS was missing a -go :) -- package name is > golang-github-bitly-go-simplejson for those at home -- as a result, > your > Vcs-* headers look a bit off :) > >>> > >>> Yes - sorry about that. The extra -go is necessary. > >>> > >>> I've updated the Vcs-* fields now. > >> > >> Looks great. I spotted an issue where d/control claimed 0.4.3, source > >> was from 0.5.0. Tim's on the job, just noting it for the channel. After > >> that's clear, it looked good to me. > > > > I investigated a bit and decided to rename the version number to > 0.5.0-alpha to > > reflect what’s in the code. Good catch though. > > > > This should be ready for uploading now. > > > > > > Thanks! > > > > Tim. > > ___ > > 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
Re: [pkg-go] RFS: golang-github-bitly-simplejson
• debian/* is licensed under GPL-2+, but upstream is MIT. Consider using the same license to avoid headaches when shipping patches. • The package does not build with gbp: /tmp/golang-github-bitly-go-simplejson master $ gbp buildpackage --git-builder='sbuild -v -As --dist=unstable' gbp:error: upstream/0.5.0-alpha_git20150401 is not a valid treeish On Fri, Sep 11, 2015 at 1:30 AM, Potter, Tim (Cloud Services) wrote: > On 9 Sep 2015, at 2:07 pm, Paul Tagliamonte wrote: >> >> On Wed, Sep 09, 2015 at 03:46:41AM +, Potter, Tim (Cloud Services) wrote: >>> On 9 Sep 2015, at 1:34 pm, Paul Tagliamonte wrote: On Wed, Sep 09, 2015 at 03:28:59AM +, Potter, Tim (Cloud Services) wrote: > Hi everyone. This package is required for bugsnag and I’ve just finished > renaming > it and testing against the new naming policy. > > Could someone please review and upload? Ah, your RFS was missing a -go :) -- package name is golang-github-bitly-go-simplejson for those at home -- as a result, your Vcs-* headers look a bit off :) >>> >>> Yes - sorry about that. The extra -go is necessary. >>> >>> I've updated the Vcs-* fields now. >> >> Looks great. I spotted an issue where d/control claimed 0.4.3, source >> was from 0.5.0. Tim's on the job, just noting it for the channel. After >> that's clear, it looked good to me. > > I investigated a bit and decided to rename the version number to 0.5.0-alpha > to > reflect what’s in the code. Good catch though. > > This should be ready for uploading now. > > > Thanks! > > Tim. > ___ > 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
[pkg-go] dh-make-golang_0.0~git20150913.0.1221041-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 13 Sep 2015 18:31:23 +0200 Source: dh-make-golang Binary: dh-make-golang Architecture: source amd64 Version: 0.0~git20150913.0.1221041-1 Distribution: unstable Urgency: medium Maintainer: pkg-go Changed-By: Michael Stapelberg Description: dh-make-golang - tool that converts Go packages into Debian package source Changes: dh-make-golang (0.0~git20150913.0.1221041-1) unstable; urgency=medium . * New upstream snapshot. Checksums-Sha1: 4b288a806fc6aea18b0e100905bc5623f2a4d2f7 2253 dh-make-golang_0.0~git20150913.0.1221041-1.dsc cddb299b8f7758d8ea830434599b0b5ebfc58ad5 11796 dh-make-golang_0.0~git20150913.0.1221041.orig.tar.xz 589a9ed71b23f6670d0177f5ce1eb616b1a923fd 2372 dh-make-golang_0.0~git20150913.0.1221041-1.debian.tar.xz 600f3de20938738d7697eaa46037212631d94844 1266764 dh-make-golang_0.0~git20150913.0.1221041-1_amd64.deb Checksums-Sha256: 456487f8a5251e8f5d7085c9031c3784f61f817dfa3baa6a8a70b53e1110e1c5 2253 dh-make-golang_0.0~git20150913.0.1221041-1.dsc c86f8fe5109a43ddedaa204e9fc506e60d0f4f032c497682ca01d5a662796821 11796 dh-make-golang_0.0~git20150913.0.1221041.orig.tar.xz d808575f45088ecdbd1923dd08a02a0238cfc82e0df2020f19adc522d357d013 2372 dh-make-golang_0.0~git20150913.0.1221041-1.debian.tar.xz 2bd65d8bd1eac65ed8986b66a0c5d37214f3dc55cfa7d6dd45e1bab7059bc948 1266764 dh-make-golang_0.0~git20150913.0.1221041-1_amd64.deb Files: 1b136fd17d6a411eddee6d51330948f3 2253 devel extra dh-make-golang_0.0~git20150913.0.1221041-1.dsc a1de3df259c858fc2a5653625e355cbe 11796 devel extra dh-make-golang_0.0~git20150913.0.1221041.orig.tar.xz 144d73aee9b67ec8cec41d0705cc15b2 2372 devel extra dh-make-golang_0.0~git20150913.0.1221041-1.debian.tar.xz 92d462ceb93f7b3819e105b8bc16cfc5 1266764 devel extra dh-make-golang_0.0~git20150913.0.1221041-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJV9aV3AAoJEE5xYO1KyO4dCYkP/im3y0IJ+hu0aYKbftYvtbNT DeSbF9N7R/uIfDxpHGrFL7E3fPlZbQkJHRqVnWLX/CuI2RqENZjCCQ32c1V31dL0 Bt6JV5XSVuenih4dN10Zc+d7PJ0886wmemzz68T1W79POvaKRfqceysLk4ZWm9JT 73bJSorkq/iuyflrXQ7TYHYAsSNlbAn8xWxprDOwuRKBJh0w/BGfbO3al90jgXLv vLaK1OyOLrQYYKlwvN2eyG+hozPQOIVOckTm6SJ6Gwx4tMQmltTQleHtsTxsjF4n zh4R216vQJk5J/WxzC2lTluBTydWB6C3qbyTrkInlUK9hMZUKFuei/nN6cn7T3Iw 82XbjC10nm16Zzzy6Cl3IJYGYA9KEQiDi69/wuVPw7jG6jjetOxsBs6UzIIICFrH Yxs3ml/pt/GAoEFx7r4P2RvIv6FH6RD9/cJX1Zel8nZmjazSlaeviprP58qFHpyG ztmAAuNK3zCEcOKWwVH+mvrS2tr4WYdDhqltfidqGRK8EVKHKFsQJ9qOKh/VyRwW nglnoNtwztJlWXGwOU6BN1fTON9M1YJa0oKIWGaTSd11uXGtuvlqw7PdvdWKXbs5 RgxpgH8qTHL5e5JKaZ5GZl1rJXWs4AnMmhHxopc13IGV3EB1eX0VOU/6XG1jtbjV U/i0bdMuQhkiETqlUexo =cOhu -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] golang-go-zfs 2.1.1-1 MIGRATED to testing
FYI: The status of the golang-go-zfs source package in Debian's testing distribution has changed. Previous version: 2.1.0-1 Current version: 2.1.1-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Processing of dh-make-golang_0.0~git20150913.0.1221041-1_amd64.changes
dh-make-golang_0.0~git20150913.0.1221041-1_amd64.changes uploaded successfully to localhost along with the files: dh-make-golang_0.0~git20150913.0.1221041-1.dsc dh-make-golang_0.0~git20150913.0.1221041.orig.tar.xz dh-make-golang_0.0~git20150913.0.1221041-1.debian.tar.xz dh-make-golang_0.0~git20150913.0.1221041-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Usage of Built-Using for dev packages
I’ve updated the policy in commit https://anonscm.debian.org/cgit/pkg-go/website.git/commit/?id=98531f7af530cbb571429a680e86a57ab936e86f On Fri, Sep 11, 2015 at 10:02 PM, Alexandre Viau wrote: > Hello Michael, > > On 11/09/15 03:57 PM, Michael Stapelberg wrote: >> That’s a fair point as well. Do you want to file a bug against the >> package in question? > > I will. > > Should we also update our policy? We could state that tools should be > shipped in -tools packages and that -dev packages should only contain > the source. > > -- > Alexandre Viau > alexan...@alexandreviau.net > -- 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
Re: [pkg-go] Various problems with packages in the group
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) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Various problems with packages in the group
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 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 > ' 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
[pkg-go] Various problems with packages in the group
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 ' 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) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
