On Sat, 23 Feb 2008 11:20:55 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
>> Now, you are trying to make me go towards a mechanism I think is
>> inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>> shaky linear patch series) as opposed to pure, independent feature
>> branches, for benefits I still think are dubious, so expect serious
>> push back. Especially if for every upload I'll have to redo all the
>> integration work of the past; ain't gonna happen.
>> I am not trying to convince you of the error of your ways. Please
>> desist trying to convince me of mine.
> No one, not me, nor anyone else in this thread that I've seen, is
> saying that you should abandon your sytem. What we want is a
> consistent method of dealing with differences from
> upstream. Currently, we have one giant .diff.gz, which people hack
> around either with patch systems or vcs's. If we switch to something
> other than a monolithic .diff.gz on top of a .orig.tar.gz, then we win
> because currently we just have a lot of chaos.
So far, this is OK. The devil, though, lies in the details.
> No matter what you want to say about your feature branches, you *must*
> apply them in a linear fashion to your final source tree that you ship
> in the package. This is no way around it.
But there is no such linearization, not in the way that quilt et
al do it. The state of such integration is not maintained in the
feature branches; it is in the history of the integration branch. As
each feature branch was created or developed, if there were any
conflicts, these conflicts were resolved in the integration branch. And
the integration branch does not keep track of what changes come from
which branch -- that is not its job. And it does not keep the
integration patches up to date either -- that again is not its
job. Details below.
There are only Two use cases I care about. A) Feed each pure
feature to upstream as an up to date patch against current upstream --
this is what the feature branch does. B) Have an integrated source of
all features ready to compile for Debian -- and easy to keep updated
with lates revisions. This is the task of the integration branch.
> This idea, a linear stack of changes one on top of the other, is the
> commonality between every one of the different means of handling
> changes to upstream, be they maintained by a patch system or a
> vcs. What we want is to stanardize this concept so that our general
> tools like dpkg are aware of it.
This is where we start to differ. More on this below.
> Given what I know about your system, the only change you would have to
> make is that instead of integrating directly in a final branch, you
> generate a diff and throw that along with the diff's name in to
I do not think you have thought it through. Let us try seeing
how this will not work: Say I have have feature branches A-F. When
development happens on branch A that requires some conflict resolution
on the integration branch, I do the resolution, and fix up the
integration branch. The fix applied depends on what order the features
were merged in -- and this is not something I need to keep track of, so
I do not.
As more development happens, and non-overlapping
changes in the same area occur, the patch would no longer apply. Other
feature branches may make changes in the area; and again, make the old
The a new upstream version comes along, and more changes
happen. By this time, the old patch will not apply even to
upstream. Now rinse and repeat -- the patch you blithely threw into
./debian/patches is just dead bit by now.
> That's it. It could be totally automated from your
> current setup without much work, if that's what you want.
I don't think this can be automated. However, if you think you
can solve the problem, I'll stand down my objections. Love to see it
Indeed, the only way to redo the information in the integration
branch is to start with the original upstream, from several years ago,
determine which feature branch was merged in what order, what order any
improvements were applied, redo the conflict resolution patches, redo
the upstream version updates in the correct order, and get to the
current integration branch.
Heh. Good luck.
> This is not making you give up anything, it's about improving the base
> standard so everyone can get more information without learning a
> zillion different patch systems and vcs's. As a result, we can focus
> on improving the code itself instead of the process of managing the
> So, in summary, stop trying to act like you're being forced to do
> something that's going to hurt you. No one is taking away your toys.
Words. Lets us see some code, eh?
When a man knows no this shore, other shore, or both - such a one, free
from anxiety, liberated, that is what I call a brahmin. 385
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
vcs-pkg mailing list