Re: How to cope with patches sanely
On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft <firstname.lastname@example.org> said:
> also sprach Manoj Srivastava <email@example.com> [2008.02.22.1627
>> 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
>> 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
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
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.
(It is an old Debian tradition to leave at least twice a year ...) Sven
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C