Hi,
On 02/06/2018 17:56, Tong Sun wrote: > I know we new maintainers need to connect the dots ourselves, but the > problem is I don't even know what dots to connect, having already read > all the go packaging materials I can find, despite the fact that I know > how to maintain normal Debian packages, and have already maintained > several. E.g., this is the first time I realized that gbp is involved (I > admit that I only paid attention to the comments/instructions, not lines > after lines of the code. Well, to be accurate, I noticed the `gbp` three > character when I first read > https://pkg-go.alioth.debian.org/packaging.html, but I had no clue what > it is and had made a todo item to lookup for what `gbp` stands for). As a side note, it's still not mentioned on the start pages (the current one, https://go-team.pages.debian.net), but the team agreed a while back to change a few things: https://go-team.pages.debian.net/workflow-changes.html > Maybe it is a more a personal taste, but I'd like to read before leap. We (go team) are definitely lacking a bit in this area. It's not that we don't have documentation and good practice, but some are still in the making and they are hard to find. Asking the Mailing List or IRC is always a good idea. As a beginner, that's what I do as well ;) > I'd like to use the same approach for go packaging as well, if possible, > but I have found so many missing steps when it comes to go packaging. > E.g. (apart from what `gbp` stands for) what steps needs in turning from > https://github.com/containerd/continuity > to https://salsa.debian.org/go-team/packages/continuity? > > maybe it is really trivial, but then it doesn't need much explanation > either. Otherwise, it becomes a missing step for new maintainers. Actually, appart from the specificity in "workflow changes" I mentioned above, dh-make-golang documentation and git-buildpackage (gbp) documentation have step by step instructions. It's true it could be better - and I'm sure we welcome help in this area ! The thing is, GBP is kinda ubiquitous in Debian nowadays, at least in teams. Once you get some basic concepts, the workflow changes doc above makes sense. just in case you don't have it already, GBP documentation: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html (also locally: /usr/share/doc/git-buildpackage/manual-html/) > Moreover, speaking of gbp, is it still the correct tool to use when I'm > also the upstream author? E.g., will the 3 branches: 'master', > 'upstream' and 'pristine-tar', still necessary? Or we'd better keep them > separated just like > what https://salsa.debian.org/go-team/packages/continuity is doing? But > wouldn't it double the amount of work? > Not exactly sure what you mean, so I'll just assume, please correct me if I did not get you. I think upstream development and debian packaging should be separated. I am upstream for openpgp-applet (hosted on salsa), and I package it in the perl team separatly, following the procedures of the team. And sometimes someone from the team fixes stuff in the packaging, which is great, and the reason I want the package team maintained. It is a different work after all - even if as an upstream, I try to be nice to myself as a Debian packager ;) The idea is that whatever my worflow is as an upstream, it's better if all packages of the same sort are done the same way, that way anyone can work on it. Especially in teams where there are a lot of package like ours. You never know when you'll have to do work on many packages at once (a recent example is migrating from alioth, but it could also be a change in policy for instance). So we need to have all the packages packaged the same way, if we want them team-maintained. Regarding the branches, please refer to the workflow change document I linked above, there are a few things that are different from the "standard" gbp workflow. For instance, we don't use pristine-tar anymore. > Overall, I know it is not hard for all your experienced go maintainers, > but some might have forgot how hard it was for the new comers to pick > up. Well, I must stop complaining, and give up my "look before leap" > motto, and start cracking... > Hope this helps a bit. Feel free to share notes: we could use this as a way to improve our documentation, at least. Cheers, and thanks for your work :) -- nodens _______________________________________________ Pkg-go-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
