[pkg-go] Minutes for the DebConf17 BoF

[Michael Stapelberg]

Sorry for taking so long to reply with this, but I’ve had little time recently.

I think that, at this point, it makes sense to structure the
discussion a little bit more. To that end, I would like to step up as
moderator, and have also created an etherpad, which should allow for a
more pleasant form of collaborative communication around documented
goals than a seemingly endless email thread (I can’t keep it in my
head).

Please give it a look at
https://oasis.sandstorm.io/shared/l4YsLYdwUgnhzzwmKS_TGwWyVQ9Ol8EKiMR8qhpHaS2
and add any remaining discussion points you would like to bring up
within the next 14 days, i.e. no later than 2017-11-04.

We can continue the discussion longer than that, but we need to cap
the volume of what we talk about at some point.

In case we can’t decide on all pending topics within November, I
suggest we do a vote in early December, then find volunteers to help
with implementing the decisions we make — New Year’s resolutions? ;-)

I’ll periodically remind people of outstanding work items because the
etherpad has no email notifications.

On Sat, Oct 7, 2017 at 12:08 PM, Alberto Bertogli
<albertito at blitiri.com.ar> wrote:
> On Tue, Aug 15, 2017 at 11:02:39PM +0200, Michael Stapelberg wrote:
>> 6. I have come to appreciate pristine-tar, as it is the only reliable way
>> (that I know of) to prepare uploads for packages which already have their
>> orig tarball in Debian. Whenever I come across a package which isn’t using
>> pristine-tar, the generated orig tarball will have a different checksum,
>> and my upload will be rejected. I’d suggest we codify that pristine-tar is
>> a requirement.
>
> As someone very new to packaging things for Debian, here are my 2 cents.
>
> For projects with an upstream git repository, I find packaging using two
> branches to be much easier and practical:
>
>  - One branch "upstream" which follows uptream directly.
>  - One branch "debian" which is based on "upstream" + patches to the
>    debian/ directory.
>    To update the package, I just do "git merge upstream" and then make
>    the required changes to the debian/ directory.
>
> I find this result in a repo with clean and useful history, as I can
> clearly see in the "debian" log the points where the package was brought
> up to date, and what changes it required. It also means there's no easy
> way to accidentally import a mutated upstream (which can happen if one
> just takes snapshots) so it's harder to make mistakes.
>
>
> No pristine tar branches, those I find terribly confusing and
> unnecessary: if everything is in the git repository already, why take
> it, turn it into a tar, and shove it back into git again? This requires
> additional tooling and maintenance for, what I can see, no real gain.
>
> I noticed that "gbp buildpackage" works just fine without it, and can
> build the tar based on the git repo just fine, and in a reproducible
> way. The generated tree is 100% reproducible, the points of
> non-reproducibility are tar and compression so they're should be rare.
>
> Asking around, it seems that needing the tars is not that common; and
> when needed, they can be downloaded from the archives anyway if tar/gz
> happened to have changed.
>
>
>> > dh-make-golang
>> > --------------
>> >
>> > A few times people expressed the desire for dh-make-golang to grow an
>> > `--update` option, as most packages are trivial to update, but tedious
>> > to do so.
>
> This * 1000 :)
>
> I imagine it would require some assumptions about the way the packages
> are handled (branch naming, how upstream is tracked, etc.), which makes
> having some degree of consensus about it even more important.
>
>
>> > API changes in upstream
>> > -----------------------
>> >
>> > We ranted at length about upstreams, and noted that we need a system
>> > that provides early warning of API breakages. We discussed using ratt
>> > and autopkgtest for that purpose.
>> >
>> > Aviau pointed out that he usually requests upstreams to make releases
>> > and that he is usually successful. Tincho pointed out the problems with
>> > meaningless releases and with upstreams releasing once and then
>> > forgetting to do it when needed.
>> >
>> > We discussed the possibility of changing "soname"s by renaming packages
>> > when we detect API incompatibilities, but concluded that in general it
>> > is too much work and that it makes more sense to try and fix
>> > reverse-dependencies by bugging upstream or patching them ourselves.
>
> For C, there were at some point public API checkers that take your code
> and will send you a warning if you make breaking changes.
>
> I think such a tool for Go would go a long way with this. You can give
> it a "go get"able package, and it would track it and report when the
> public API changes, and warn of incompatible changes.
>
>
>> >   * aviau volunteers to document dh_golang options.
>
> As a newbie, I'd really appreciate this!
>
> I often just rely on asking on IRC or to Tincho directly, because the
> way it works seems quite opaque to me.  Luckily most of the things I've
> touched so far have been simple enough not to need this.
>
>
> Thanks!
>                 Alberto
>



-- 
Best regards,
Michael