Using quilt to store patches

[Stéphane Glondu]

Hello,

martin f krafft a écrit :
> From what I understand, Mehdi's (and Guido's) approach require
> a branch with one-patch-per-commit, which they rebase. This approach
> has two problems for me:

I do use this approach, too. Actually, I took the idea from Guido's
packages and taught it to Mehdi and Stefano (and will probably to the
remaining of the OCaml Team) ;-)

> 1. due to the rebasing, it's not possible to work with other people,
>    unless everyone maintains their own patch queue.
> 
> 2. each patch on the patch queue branch is presumably the result of
>    a squash-commit or the like. The feature has likely been
>    developed on a branch of its own, squashed into a single commit,
>    and then removed.

You sound like you are developing "complex" features in your Debian
packages, features that might be concurrently developped inside a
packaging team. This doesn't sound right for me. I never do such complex
development inside a package. Most of the time, patches are just fixes
to make the upstream package more Debian-friendly, or patches taken from
upstream's VCS. But maybe I don't maintain "real-life" packages...

TopGit seems great if you actually do upstream development without being
formally upstream (i.e. don't have direct commit access), in
collaboration with other people. IMHO, this doesn't match the task of
packaging for a distribution.

Don't be mistaken: I don't say that packagers must not work on upstream
features; I just say they shouldn't do it as part of their Debian packaging.

>    If the patch needs modification later on, you have to recreate
>    a branch and work off the single squash-commit. While this
>    prevents you from looking at history, the bigger problem is that
>    it's repetitive manual work: create branch, cherry-pick patch,
>    work, squash-commit delete branch.

This "manual" work is trivially scriptable. The same way as TopGit's
work could be done "manually" ;-)

>    It gets worse if you do publish the feature branch, because then
>    you need to keep it up to date with other branches by merging
>    before you can work on it and squash-commit.
> 
> TopGit automates all of (2) and since it never rebases, it can be
> used in a team (1).

The feature branch is not meant to be exported, nor touched frequently,
only on new upstream release and Debian releases that fix bugs in
upstream. For my own packages, this doesn't happen often (but of course,
I am aware that this might not be the case for everyone).