[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback on 3.0 source format problems




On January 4, 2017 6:23:23 AM EST, Jonas Smedegaard <jonas@jones.dk> wrote:
>Quoting Vincent Bernat (2017-01-04 08:12:08)
>>  ❦  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)
>
>Do _any_ of the systems reliably handle a "git rebase" involving a
>merge 
>of new upstream release?  In my experience gbp also fails that.

My experience with git-dpm, including with packages that have stacked patches/commits, is that it's pretty reliable, although not perfect. In the end, most, if not all the problems I've had turned out to be pilot error.

Scott K


Reply to: