Re: How to cope with patches sanely
On Sat, 26 Jan 2008 11:34:27 -0500, David Nusinow
<dnusinow@speakeasy.net> said:
> What bothers me about Joey's blog entry, and other similar proposals,
> is that it ignores a major reason for having external patch systems in
> the first place. Many of us have to carry long-lived patches to very
> complicated software. I'm personally thinking of the X server, but
> there are bound to be other examples. Additionally, we often have to
> carry several of these throughout the lifetime of the package. We also
> have to carry patches that aren't yet suitable for upstream, but may
> eventually become so. Finally, we have to carry patches backported
> from upstream HEAD.
I have beeing doing this for some of my packages using arch; and
while none of my packages are as large as X, it has worked out quite
well for me.
> The idea proposed by many people, to keep the patches merged in your
> debian-specific branch, only really improves lives in the last case,
> when those patches are going to be merged in for the future anyhow. In
> any case where you have a patch that isn't going to go upstream for a
> long while, if ever, keeping these patches merged becomes painful.
This has not been my experience with feature branches +
integration branch.
> If the patches are large, then you'll forget most all of the details
> which makes merging painful. Additionally, it becomes quite difficult
> to see a large patch that touches many files in the whole. A great
> deal of archaelology becomes necessary to cope with that. If the patch
> becomes suitable to go upstream after some time, it also becomes hard
> to extract that patch to be sent later.
> An alternate idea I keep seeing is feature branches. I have absolutely
> no idea why these are considered preferable to most people. In the
> case of the X server we regularly carry around 30 patches on our
> stack. If we were to put each of these on its own unique feature
> branch, merging them becomes an exercise in pain. Sure, we could
> implement our own custom scripts and have very strict naming policies,
> but then you've re-invented the wheel and congratulations, you have
> yet another custom piece of crap software that you have to maintain on
> top of the already complicated one you actually care
> about. Additionally, you have a lot more branches getting in the way
> when you're trying to figure out which one you're looking for.
In my experience, once I have created the integration branch,
most upstream versions require little to none re-merging; I just apply
the delta to each of the feature branches, _and_ the integration
branch. Very rarely do I have to fix up a feature branch, and then
apply a second delta with that fix up to the integration branch; but it
has not been, for me, painful at all, nor do I have to jump through
hoops every single time to accommodate new upstream.
> If we can't figure out a good and clean way to keep a large stack of
> long-lived patches in the vcs then I firmly believe we should
> standardize on quilt.
I think I have indeed solved the issue of long standing feature
sets using feature branches, integration branches, and sloppy branches
while upgrading, and would not want to be forced to regress to a patch
system.
manoj
--
Usage: fortune -P [] -a [xsz] [Q: [file]] [rKe9] -v6[+] dataspec
... inputdir
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: