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

Sat Feb 22 19:54:16 UTC 2014

Hi,

micah wrote (20 Feb 2014 16:31:27 GMT) :
> I guess I prefer the atomicity and "legibility" of separate patch
> files. It just makes things a lot more obvious to me what is going on,
> rather than burying these things deep in a subway map train wreck of a
> git history. I like separation into files because it makes it really
> simple to just go an look at a source package and find what is being
> changed from the upstream source by just looking at files. With things
> in git I need to push the Rubik's cube of a particular packaging team's
> git workflow into my brain for an hour just to figure it out. Then if
> you actually want to make a change, you have to actually solve that
> Rubick's cube! 

> Yes, there is a certain elegance to doing it all in git and using
> branches and cool stuff like that, but when it requires that people draw
> beautiful ascii git diagrams just to explain it, that indicates to me it
> has gotten too complicated for words.

I've had my share of similar experiences, and I can easily empathize
with everything you wrote. I agree we should try *not* to need ascii
diagrams to explain how we work. I agree that separate patch files are
very simple.

While we're at sharing feelings, the process that produces these patch
files does not look simple to me: while Git is a language I speak
easily these days, and many people are learning it for a reason or
another, I could never understand quilt properly, and too often I end
up resetting --hard and rm -rf .pc because, oh well, I've edited
a file and I should have told quilt before, or something. I can teach
Git to people, but I don't feel I can easily teach them quilt.

Anyway, I think we're mixing many different problems here, and I'll
now try to address them one after the other.

1. Making it easy for NMU'ers, security team, etc. to produce
   a patched package
-------------------------------------------------------------

Source format 1.0 makes this really easy: `apt-get source', apply
patch, build, done. Alternatively, `debcheckout --auth', apply patch,
commit, build, push to Git, done. Of course this must be documented,
else I agree it can be a pain just to figure out that... in fact, it
was so simple!

3.0 (quilt) makes it equally easy for anyone familiar with quilt.
Admitedly, this source format is almost standard in Debian these days,
and we can assume that most people with upload rights know their way
around it.

So, for #1, I don't see any decisive advantage one way or another.

2. Making it easy for newcomers to join our team
------------------------------------------------

My guess is that for already skilled packagers, it doesn't make much
of a difference if we pick 3.0 (quilt) or 1.0 (pure Git). In one case,
that's probably what they're used too (quilt-induced pain included),
while in the other case, that's pretty simple but they might have
forgotten how 1.0 format works.

For people learning packaging, it's a different story. I'm convinced
that *not* having to learn quilt lowers the bar seriously, so 1.0
seems interesting. OTOH, it's also clear to me that learning the
"standard" 3.0 (quilt) workflow makes the time investment more worth
it: you can reuse this knowledge to work on many other packages.

So, for #2, I don't see any decisive advantage one way or another.

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.

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?)

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.

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?

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.

6. Making it easy to see what is being changed from upstream source
-------------------------------------------------------------------

No doubt, 3.0 (quilt) is the clear winner here.

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.

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.

> 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.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc