❦ 4 janvier 2017 04:52 GMT, Scott Kitterman <debian@kitterman.com> :
>>> It's surprisingly awkward, and, at least for me, it turns out that
>>> externalizing my rebased branch as a patch series solves many of
>>> problems surprisingly well. All the other solutions I can think of
>>> require one or more things I don't really want to do: rebase the
>>> debian/master branch, not be able to run dpkg-buildpackage from the
>>> debian/master branch easily, or require that dpkg-buildpackage do
>>> more mucking about with source control than I want it to.
>>
>>I believe the git-dpm approach would give you everything you want. The
>>explanation on http://git-dpm.alioth.debian.org/ is pretty good.
>>
>>I personally think that technically git-dpm's approach is the best -
>>but
>>unfortunately the program itself is effectively unmaintained and
>>apparently/consequently not used by many people.
>
> The Debian Python Modules Team (DPMT) has about 1,000 packages with
> git-dpm repositories. While it took a bit of getting used to and
> there have been a few problems, overall I think it's worked very well.
> It's biggest problem is the lack of a maintainer.
There have been a lot of complaints about it. For me, it is a pain to
use. Its integration with gbp is poor, it produces a messy history when
you are working on your patches and I often run into problems with
.debian/.git-dpm file it maintains (import a new upstream, make some
changes, notice that somebody else also pushed a change, pull --rebase,
everything is broken). Since we started using it, we opened a lot of bug
reports and not a single one of them has been fixed. I think that nobody
wants to work on it because it is an extremely fragile tool and the
first one to try to fix it will inherit of all the problems to solve.
Isn't "gbp pq" a correct execution of the same principles?
--
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature