How to cope with patches sanely

[Manoj Srivastava]

On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft <madduck at debian.org> said: 

> also sprach Manoj Srivastava <srivasta at debian.org> [2008.02.22.1627
> +0100]:
>> I am not sure you have understood feature branches.  They are
>> independent, no matter what the overlap. Each feature branch tracks
>> one feature against upstream, no matter how the other features work.
>> 
>> The overlap management is done in the integration branch. This is
>> significantly different from a quilt series, as others have already
>> mentioned in this thread,which is a dependent series of linearized
>> patches; and a change in an earlier feature impacts all subsequent
>> patches (and quilt is good at automating the handling of that
>> impact). [[duplicated so this can be archived on the vcs-package
>> mailing list as well]]

> well, I know what feature branches are but I suppose I jumped the
> gun. They are independent until you integrate them. But you will
> integrate them, thus I tend to think of them as interdependent from
> the start.

        You have a strange definition of interdependent.  The majority
 of my feature branches are really orthogonal;  seldom on integration
 there is no conflict; so it is hard for me to think of them as somehow
 inter dependent. Sure, there are overlapping changes, sometimes, but
 these are mostly one time resolution issues.

> Anyway, we're not talking about developing with quilt. We are talking
> about converting feature branches to quilt patches for the sake of
> representation in the source package. I don't see why you would oppose
> to that at all, to be honest.

        I am not opposed to it. If you can somehow magically create a
 tool that can linearize the feature branches, more power to you. I
 personally find the prospect highly unlikely; and I would like to see
 some code, please, before I grant that such a thing is possible.

>> Or the patch manager does integration. *Shrug*.  Someone has to do
>> integration sometime.  That is the nature of the beast.  The trick is
>> to do it once, and never have to think about it again.

> ... except when one feature needs to change and then conflicts with
> another feature on re-integration.

        Sure. You can't integrate two features that fundamentally
 conflict with each other. No amount of smoke and mirrors can obscure
 that fundamental obstacle. This is independent of the tool set you
 use. 

>> B) Development happens on the feature branch.
> [...]
>> 2) Development on one of the branches conflicts with one or more
>> other features. Here, the human has to figure out the difference on
>> the integration branch -- once.

> No, every time you do development on the branch. And every time, you
> have to remember which branch dependended/conflicted on the feature
> branch you're currently working on, or figure it out by trial and
> error. I don't consider this efficient. This is work that a computer
> should be doing.

        Strange. In all my years of using feature branches, I have never
 had to consider which branch depended on what. So no, I don't think I
 _have_ to remember any  such thing; trust me, I would have noticed.  I
 have 30+ packages, and have been using feature branches since  early
 this decade.

        If you have a whole slew of features that depend on other
 features, then your feature set is very different from ones I have
 encountered. Dependent features do require more work; but not as much,
 in my opinion, as using quilt or dpatch; but your mileage may vary.

        For the most part, I just develop on each branch independently.
 I compile, test, hack, compile, on each individual featre branch. And
 never ever worry about what the other feature branches are like, while
 doing so.

        Once in a blue moon (more or less) I have to deconflict the
 integration branch; but mostly those are swiftly resolved issues. And
 once resoved, I tend to forget about them too.  All this worrying about
 branch conflicts seem to be more the realm of quilt and other patch
 series mechanisms; which is mostly my reason to dislike them.

        manoj
-- 
(It is an old Debian tradition to leave at least twice a year ...) Sven
Rudolph
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C