[pkg-otr-team] gbp vs. 1.0 source format

[Antoine Beaupré]

First off, I want to be clear here that I assume that "1.0 (pure git)
format" means the regular "1.0" source format with an outside git
repository, not the actual "3.0 git" source format, which would seem
like a more appropriate target for the "pure git" name. :)

On 2014-02-22 14:54:16, intrigeri wrote:
> Hi,
>
> 1. Making it easy for NMU'ers, security team, etc. to produce
>    a patched package
> -------------------------------------------------------------
>
> So, for #1, I don't see any decisive advantage one way or another.

Agreed.

> 2. Making it easy for newcomers to join our team
> ------------------------------------------------
>
> So, for #2, I don't see any decisive advantage one way or another.

Agreed.

> 3. Making it easy for us to forward patches upstream
> ----------------------------------------------------
>
> I think both source formats make it equally easy. In one case, one can
> prepare their patch in a branch forked off upstream's, and use `git
> send-email'. In the other case, one can prepare their quilt patch they
> way they want, and email the patch file.

That, however, I am not sure.

The 3.0 (quilt) format is quite easy to understand:

 1. create a patch in debian/patches
 2. add it to debian/patches/series

I never actually used the quilt command for this.

Now of course, this works if patches are not incremental (ie. if they
don't touch similar areas of code), but that's been usually the case for
packages I worked on.

With git, you actually have to create a new branch, figure out what has
already been patched, etc, etc. I am not even sure how we trace those
patches at all, if they haven't been sent upstream already. The
discussion around my proposal for a "patches" branch seem to show we
don't have a clean solution for this at all.

So it's much easier and much clearer to figure out what actually *are*
the patches with upstream with 3.0 (quilt).

> 4. Making it easy for us to track which of our patches have still not
>    made their way upstream
> ---------------------------------------------------------------------
>
> At "import new upstream release" time, the clear winner here is 3.0
> (quilt): a patch that was integrated upstream won't apply and the
> build fails. (But well, why do we care noticing that a patch was
> integrated upstream at *that* time, and why having to do some stupid
> work accordingly would be an advantage?)

It's an advantage because we "fail close". If the patch was integrated,
we remove it explicitely, if not, we can lobby upstream again.

With 1.0 (pure git), we have no notification of patches being included
upstream at all, and could potentially stay with those forever. And the
more time passes, the harder it is to figure out why those patches were
there.

> At any other time, I think both are painful. Our quilt patches series
> is no way to get the up-to-date answer, and looking at the upstream
> Git repo to see if our quilt patches were integrated has never been
> pleasant to me. With 1.0 (pure Git), we have `git log --grep', which
> requires quite some manual operations too.

It seems you are assuming we have a way to find which patches actually
exist in our repo. I haven't figured out how to do that cleanly yet, and
I haven't seen a proposal that does.

> An interesting question might be: at what time are we interested in
> knowing the answer to: "which patches of ours haven't been integrated
> upstream yet?"... and what do we do with the answer?

I want to do this at every new release, but others may want to do this
on a more regular basis, for audit purposes. Upstream may look at the
patch tracker to figure out what we did to their software during a
support request for example.

If it's only one blob, it will be harder for them to make sense of
things. And if they look at the git repo, they go back to the problem of
finding which patches are for upstream, and which are relevant to the
debian/ directory. Something I wouldn't want to bother upstream with.

> Doing so when importing a new upstream release seems a bit late to me:
> ideally, upstream would have applied our patch *before* doing their
> release, not after. Personally, I need the answer when I'm ready to go
> nag upstream about my pending patches, and I try to do so every month
> or so, or a bit before their next feature freeze, depending on their
> release cycle. I'm very low interest in the answer at any other time.
>
> Perhaps an acceptable answer is 1. get upstream a bug tracker (WIP);
> 2. have them create a "from Debian" tag or similar; 3. create a ticket
> there for every patch we apply (we want to forward our patches
> upstream, so we have to do it anyway, right? :) ; 4. regularly get the
> list of such open tickets, and gently ping upstream.
>
> 5. Making it easy for us to maintain patches we apply to the upstream
>    source
> ---------------------------------------------------------------------
>
> No doubt, 1.0 (pure Git) is the clear winner here.

I am not sure i see why - unless we have a branch for each patch, if we
want to modify the patch, we need to make a new commit, which will
fragment changes in that patch in multiple commits, something upstream
may refuse. It also means we can't group those changes by meaning,
something which having a debian/patches directory does clearly and
unambiguously.

> 6. Making it easy to see what is being changed from upstream source
> -------------------------------------------------------------------
>
> No doubt, 3.0 (quilt) is the clear winner here.

You know, maybe there's something we're missing! :) It could be that
some other team or developper has developped a magic workflow for
this...

> To sum up, IMO there's no clear winner for #1, #2 and #3; for #5,
> 1.0 (pure Git) wins, while for #6, 3.0 (quilt) does. The decisive
> question is probably #4, which depends a bit (as far as 1.0 Git is
> concerned) on things that we cannot easily predict.

Well, #4 depends on #6 - the whole problem is finding which "patches"
(as in "set of related commits addressing an issue", which are really
"branches" in git) are relevant to upstream, which are relevant to us,
and so on, so basically - finding what changed from upstream.

If 1.0 pure git can provide us with such a tool, I'd be happy to use it,
but in my experience with such systems (and with 3.0 single patch, for
that matter), it's been quite difficult.

> Frankly, I would be a bit sad not to experiment with a pure Git
> workflow within this team, *but* I have other occasions to do so, and
> I see the advantage of going for the standard. I could live with us
> using 3.0 (quilt), if that's where the consensus is headed to.

At this point, I would be perfectly comfortable with any of the three
solutions (1.0 pure git, 3.0 quilt, 3.0 quilt + single patch). I think
that whoever is the uploader on the packages should decide on their own
and provide support for people that want to work on their package in the
team.

Trying to find concensus over that kind of stuff is like agreeing on the
topping of a pizza in a large group: it can't possibly work unless you
order many pizzas. :)

>> I've never heard of gbp-pq, so I can't say much there.
>
> tl;dr: gbp-pq allows to maintain a quilt patch series using Git,
> instead of having to learn quilt and deal with all its weirdness.
> I've been using it for years on 3.0 (quilt) packages, and it has made
> it almost bearable, but not enough to my taste, hence my current
> desire to try to get rid of the quilt patches entirely.

I'm certainly going to try that now, but then again, upstream irssi-otr
has merged my one patch so all of the above is mostly irrelevant for
that package right now. :P

Cheers,

A.
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
                        - Brian W. Kernighan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-otr-team/attachments/20140222/04e1aa07/attachment.sig>