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

[Antoine Beaupré]

On 2014-02-28 17:23:18, intrigeri wrote:
> Hi,

Just pursuing the discussion for the sake of argument here - I am fine
with git + 3.0 + quilt / multiple patches. :)

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

Well, that's all fine as long as upstream accepts our patches the first
time. If not, we need to modify the patch and resubmit it, and the patch
therefore becomes an "old patch". :)

We may care about those less however.

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

What i mean is the general problem if figuring out what are the patches
against upstream. In the 3.0 (quilt) world, it's a series of files in
debian/patches/

In a pure git workflow, it's a series of commit intermingled with
upstream changes and changes in debian/. It's hard to actually figure
out what those patches are and why they are there.

We have discussed a few solutions to this problem:

 1. having one "patches" branch
 2. having multiple topical branches
 3. just looking at "git log" and figuring it out
 4. rebasing against upstream constantly to keep those patches as single
    commits on top

...

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

... so my feeling now is that none of the above options are adequate to
easily track patches we have against upstream.

I think that's the whole point of #4 here.

[...]

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

I think it's a great idea, but that idea applies whatever the workflow,
and doesn't allow us to track those patches, because upstream can refuse
and close those bugs, in which case they get lost in a void.

[...]

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

I'd love to, when I have time *blink*. 

[...]

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

That seems wise. :)

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

Agreed. We can start with that and hammer out some stuff on top if we
need to.

We can even develop techniques in parallel: if we use "3.0 (quilt)",
that doesn't forbid us to have patches in the git repo somehow and
experiment with ways of tracking that better!

As long as it's not a requirement for working on the package... until we
figure out a nice "oh of course" way. :)

A.

-- 
La destruction de la société totalitaire marchande n'est pas une affaire
d'opinion. Elle est une nécessité absolue dans un monde que l'on sait
condamné. Puisque le pouvoir est partout, c'est partout et tout le temps
qu'il faut le combattre. - Jean-François Brient, de la servitude moderne
-------------- 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/20140302/bee5c5da/attachment.sig>