GIT repo: full upstream source or debian/only (was: responsibility for libgcrypt and libksba)

[Andreas Metzler]

On 2015-04-16 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> On Thu 2015-04-16 13:25:44 -0400, Andreas Metzler wrote:
[...]
>> - The packages could also be moved over to the gnupg repo and the
>>   pkg-gnupg-maint@ group with me continueing to have upload/commit
>>   rights. - If I did the bulk of the work I would strongly prefer to
>>   continue using the current debian/-only GIT layout, though.

> hm, i have a reasonably strong preference for keeping everything in git,
> including upstream code and pristine-tar deltas, for two reasons:

>  * it's easier to collaborate directly with upstream, because we can
>    keep debian/patches in a patch queue that could be applied to upsteam
>    directly.

>  * it's simpler for anyone who wants to work on the package to get
>    everything they need (including for multiple branches) in one spot.

> This is facilitated by git-buildpackage (and i've recently started using
> gbp-pq for the patch queues, which is quite nice)

> But a lot of this might just be comfort/familiarity with certain
> workflow and tools, and i don't want to get in the way of workflow/tools
> you find useful either -- can you explain what you prefer about the
> debian/-only git layout and give pointers to what tools you use to
> manage it?

Hello,

well, I think it mainly comes from what I actually do when maintaining
the package and therefore what use the repository is for me:
I am not a programmer by profession, I only maintain the packages. I
take care of the packaging infrastructure, forward bugs and pull
fixes. I generally do not develop or extend the software. (I might fix
the occasional bug, if it is a simple one.) That is the main cause why
having the upstream source in the Debian repo is just not helpful for
me. I want and need a history of changes to the packaging and tags for
uploads, the upstream changes that happen at the same time just
complicate things, especially merging, e.g. when experimental moves to
sid.[1] So taking care of properly archiving the upstream changes
is basically just a hazzle *without* *payoff* for me. (Keeping a
directory with upstream tarballs in ~/ or fetching the current one
with apt-get or uscan is trivial.)

Regarding tools: There is not a lot of it, basically just a
shellscript that untars the upstream tarball (saved somewhere in ~/)
and copies debian/ from GIT. The setup is dead simply by purpose, and
makes sure that the packages I upload are actually based on the
upstream tarballs and not on some GIT import I managed to slightly
break. (For fun, look at 367358.)

I know that this is not for everyone. e.g. if one was maintaining a
triple digit number of packages (as a day job) the time saved by having
the tarball in Debian's GIT adds up, and one would be doing lots of
GIT work anyway and won't have to think about it.

FWIW I am more or less familiar with the gbp layout git repo, I am
comaintaining two packages which use it. I can envision libksba using
it without much effort (or gain), and otoh cannot see gnutls using it
without massive pain.

cu Andreas

[1] I love having a place to browse upstream changes, but that is what
the upstream repo is for.

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'