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

[intrigeri]

Hi,

Antoine Beaupré wrote (23 Feb 2014 02:24:01 GMT) :
>> 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.
[...]
> 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).

I agree with almost everything in there, but it seems that you're
discussing "how to forward old patches upstream", while I was
discussing "how to forward new patches upstream".

Assuming we want to forward every new patch upstream ASAP, basically
at the same time as the patch is created and applied to our tree, I'm
not sure how much we care about forwarding *old* patches as far as #3
is concerned (that's more about #4).

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

Point taken.

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

Sorry, I don't get what you mean by "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.

(I don't know what you're talking about, so I'll wait :)

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

Sure.

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

I'd love to get feedback on this idea.

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

What I meant was basically "we don't have to maintain it". But reading
the rest of your answer on this point, I realize I was wrong.
Thank you!

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

I *thought* that pkg-systemd had, but they're in the process of (very
likely) moving from git-pkg + single-debian-patch to "standard" gbp,
so... anyone wanting to watch DebConf13's (or 12's) panel about Git
packaging workflows?

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

Good to know.

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

I beg to disagree. As part of the Perl team, I really appreciate
having a shared repo layout and workflow over many packages, that
allows any team member to work on any package maintained by the team,
without suprise. I think this is also key in welcoming
new contributors.

I prefer very much using a workflow *I* don't like (3.0 (quilt),
without single-debian-patch) with every otr-team-maintained package
I feel responsible for, if that avoids such discrepancies within the
team's packages.

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

:)

Well, the way I understood the opinions that were expressed in this
thread, I think we can have consensus with basically any of the three
proposals: that is, it seems that nobody will feel very uncomfortable
with any of these, and we could almost reach a consensus by picking
one at random at this point. OK, I'm using a quite feable meaning of
"consensus" here.

Still, the one that seems to make more people really at ease is 3.0
(quilt), without single-debian-patch, so I hereby propose we just do
that, and perhaps revisit this topic later, if and when the stumbling
blocks we've identified with other workflows have good solutions.

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