How to cope with patches sanely

[Manoj Srivastava]

On Sat, 1 Mar 2008 12:21:03 +0100, martin f krafft <madduck at debian.org> said: 

> also sprach Manoj Srivastava <srivasta at debian.org> [2008.02.29.2153
> +0100]:
>> 3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
>> files. Each diff, applied to the orig.tar.gz , shall recreate for the
>> interested user the corresponding branch in my development.
>> 
>> Bingo. With this addition, every user that want to see where the
>> integration branch comes from can examine each topic patch or topic
>> branch. Each of these topic branches can then be compiled and
>> experimented with.  Upstream can incorporate each of these topic
>> patches, if they wish.

> ... until I want to play with two branches at the same time, or
> upstream wants to pull two branches. Now you are forcing users to deal
> with potential conflicts.

        I am not asking users to do any such thing. I am asking
 developers who want to play with tweo unrelated and conflcting features
 to do some integration work, with my integration branch to use as an
 example to see how such conflicts can be resolved.

        If you are a developer, and want to play with conflicting or
 overlapping features, and can't do integration work given a working
 example of how such integration can be done, stay away from the
 kitchen. I am not going to jump through hoops to cater to your
 incompetence. 

>> The downside, of course, is shipping the same patch twice, once in
>> the diff.gz, and once in ./debian/branches/*.diff.gz.

> I don't see the added value in your approach. I don't see the use
> case. I know your workflow and note how this is a continuation
> thereof, but I can't identify the benefit to others and the project in
> doing this. Do you really think there are many people or upstreams who
> want pristine feature branches without being able to use the net?


        I am providing people with the same development infrastructure I
 use, in the debian source package, without impacting
 repeatability. There was a criticism that the source package that
 contains only a diff.gz is fairly opaque to developers -- and that an
 explanation should be provided to how the diff.gz came about, and what
 are its constituent parts. I am providing people a better understanding
 of each feature by putting in stand alone, and not making it dependent
 on a bunch of unrelated features.

        Let me reiterate the goals I put forth for me:
>>>  A) All the branches that I use (the pure feature branches, the
>>>     upstream branch, and the integration branch) should be made
>>>     available to the users. This will give them the same environment I
>>>     have, and thus they have the preferred place to make modifications.
>>>  B) When people do dpkg-source -x, they should have a fully unpacked
>>>     tree that is compiled, with no further action that needs to be
>>>     taken
>>>  C) In order to reconstitue all the other branches, no network
>>>     connectivity should be required.  There a lot of people in the
>>>     developing world that do not have a readily available network
>>>     connection -- my solution must work with source DVD's
>>>  D) No knowledge of my SCM should be required.  People should be able
>>>     to construct the topic branches without knowing arch or git or bzr
>>>     or Hg or what have you.

        I am also providing developers the pure features, uncluttered by
 integration junk, so people can see what the intent of the changes was,
 cleanly; and apply any such feature to upstream, and have it work.

        There is a combinatorics problem here. If you have N features,
 you might want to see them one at a time, two at a time, three at a
 time .... or N! ways. I provide the common cases: One at a time, or all
 at the same time.

        People who want the rest of the N! ways may have to do some
 integration work -- but I do provide a working, fully integrated
 example for them to program by example from.

> Why wouldn't these people be helped with a quilt series? They just
> want to work on feature B, do you think they actually care that quilt
> first pops A before it applies B, especially with tools like interdiff
> around?

        Show me the code. Get me a quilt series from my feature
 branches.  Until you can get me an automated way to get a quilt series
 from my work-flow, the quilt series option is off the table. I find a
 quilt series to be inferior to topic branches.  I understand others do
 not feel that way.  I am not forcing them not to use quilt -- though
 that would, in my opinion, improve the quality of the distribution.
 Stop trying to make me put in work to  use quilt.

        I dislike the extra work and indirection of using patches (I
 am much better at reading code than reading code + patch). I dislike
 the extra effort it takes to read code in different branches without
 doing extra work, poping and applying stuff -- and dealing with the
 integration work every time you pop and reapply and there is a
 conflict). I am never going to use quilt -- and if you try to force me,
 fffft.

        Now, if y'all put your money where your mouth is and come up
 with a quilt creator from my arch branches, sure.

        At this point, I can create the branch patches in an automated
 fashion -- though I have not yet done so for any packages uploaded so
 far.

        If you go the my way (quilt) or the high way raod, with no
 compromises, you'll end up getting nothing.

        manoj
-- 
Alimony and bribes will engage a large share of your wealth.
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C