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

[Antoine Beaupré]

On 2014-02-20 05:07:12, intrigeri wrote:
> Hi,
>
> Holger Levsen wrote (19 Feb 2014 18:41:19 GMT) :
>> cool, so now it's just irssi-plugin-otr left. AFAIK it's debian packaging has 
>> never been part of a git repo?!

That is correct.

>> Just one thing: I noticed there is no README.Source - but then we dont want 
>> this anyway, but rather document our workflow on 
>> https://wiki.debian.org/Teams/OTR - correct?
>
> I propose we ship a standardized README.source that points to the
> place (our homepage, very likely) that documents our workflow.

Yeah, I'd like to understand this better.

In the past, I have use the 3.0 (quilt) format even with git-managed
packages. I am curious as to how we track changes.

>>> The only problem I've spotted today with source format 1.0 + applying
>>> patches directly in the packaging branch is that it makes it harder to
>>> track what changes have been forwarded and/or applied upstream, and
>>> which have not. To mitigate this a bit, I propose we try hard to
>>> immediately forward upstream any patch we have to apply (done that
>>> once today already).

Right, exactly my concern as well.

>> turn it into policy instead, to only include patches which have been submitted 
>> upstream to some tracker or which have been merged upstream?! IOW: do not 
>> include patches which have not been sent upstream.
>
> Agreed, added to the wiki page.

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.

Of course that branch will mix changes from upstream but hopefully that
will be easier to figure out?

git log debian would show:

(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

git log patches would show:

(patches) second patch against upstream
(foo-1.1) new upstream release
first patch against upstream
foo upstream change
(foo-1.0) first upstream release

... which is a *little* clearer, and also allows us to diff against
master more reliably.

Just throwing an idea out there.

-- 
N'aimer qu'un seul est barbarie, car c'est au détriment de tous les
autres. Fût-ce l'amour de Dieu.
                        - Nietzsche, "Par delà le bien et le mal"
-------------- 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/f9e2ae1d/attachment.sig>