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

[Antoine Beaupré]

On 2014-02-20 10:30:00, intrigeri wrote:
> Hi,
>
> Antoine Beaupré wrote (20 Feb 2014 14:57:26 GMT) :
>> In the past, I have use the 3.0 (quilt) format even with git-managed
>> packages.
>
> Short version of what happened: I've been doing that for ages too
> (with gbp-pq to mitigate the pain),

... taking mental note of gbp-pq. :)

> and I must say I'm very tired of having to use quilt instead of Git
> for patch management, and to see diffs-of-diffs in the Git history.

I concur.

> Holger also expressed he would like to do pure Git, so the two choices
> we had were 1.0 or 3.0 (quilt) + single-debian-patch. Holger prefers
> 1.0, and I don't care much, so we've come up with this 1.0 + pure Git
> workflow.

Well, the advantage 3.0 has, if I am not mistaken, is that we have
clearer separation of the debian patches in the resulting upload, at
least...

So I would prefer 3.0 + single to 1.0.

>> So that covers part of the problem (namely patches that sit in Debian
>> ignored forever), but not the actual problem of tracking what are those
>> patches and why.
>
>> I don't know how to fix this, but maybe there could be a branch where
>> those changes would be done?
>
>> Say we have:
>
>>  * master -> upstream code
>>  * debian -> debian/ directory and patches
>
>> We could have another branch:
>
>>  * patches -> debian patches to master branch
>
>> "Graphically":
>
>> * (master)
>> |   * (debian, 1.1-1) upload to unstable
>> |  /|
>> | / * bar change in debian package
>> | * (patches) second patch against upstream
>> |/| * foo change in debian package
>> * (foo-1.1) new upstream release
>> | * | first patch against upstream
>> |/ / 
>> * / foo upstream change
>> |/
>> * (foo-1.0) first upstream release
>>
>> That way, instead of looking at the Debian branch which mixes
>> debian-specific changes, upstream and patches, we can just look at the
>> patches branch to see what's going on.
>
> This looks good, and I wanted to try that, but I'm not sure how well
> this can work in practice without rewriting the history of the patches
> branch (and I've not verified yet), and I didn't want to raise
> complicated workflow discussions while only Holger and I had expressed
> interest in this topic, so I just went with the simplest thing.

Agreed. I don't want to block anything here, just to see if people had
other opinions on this.

I certainly don't think we should rewrite history, for example...

> But well, I'm happy to dig further into it, now that I see that a few
> of us are interested in it :)
>
> So, my question is:
>
> Say I cherry-pick an upstream commit into the patches branch, upload
> to Debian. So far so good, `git log master..patches' shows me what we
> have in Debian, that hasn't been merged and released upstream yet.
>
> Then, upstream puts out a new release, that includes the patch I've
> cherry-picked. I merge their tag into our patches branch. Is Git
> clever enough *not* to show me that patch in `git log
> master..patches'?

I think so, if you merge master in patches, it should technically point
to the same commit, unless there's a merge of some sort.

> If it is, then I say we go for the "patches" branch!
> Else, I'm unsure what this buys us compared to 1.0 + pure Git.

It doesn't buy much, in any case.

I sure hope we can have some flexibility over ideas like that. If we try
to enforce too strong policies, we'll be quickly spending more time
arguing about "how" than doing things. :)

Cheers, and thanks for the hard work!

A.
-- 
VBscript: la simplicité du C, la puissance du BASIC
                        - Mathieu Petit-Clair
-------------- 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/20140220/92dc1282/attachment.sig>