Re: Breaks in lenny
On Fri, 21 Dec 2007 16:24:02 -0800, Russ Allbery <rra@debian.org> said:
> Manoj Srivastava <srivasta@debian.org> writes:
>> On Fri, 21 Dec 2007 14:04:29 -0800, Russ Allbery <rra@debian.org>
>> said:
>>> If people use branches the way that quilt manages patches, it's
>>> great, and you get everything you need, provided that you can figure
>>> out their branch and merge strategy (which is sometimes rather
>>> tricky). If they use the VCS like most people use Subversion or the
>>> like, you get a giant wad of patch, which is way less useful than
>>> what quilt gives you.
>> This sounds more like a usage issue than a toolset issue. Of course,
>> you could be argyuing that quilt somehow encourages better policies
>> inherently, as opposed to a version control system, but I would have
>> to see some data backing that claim befire I would entertain it.
> Yes, that's basically what I'm arguing, but I'm not sure I have the
> data to prove it either.
>>> Yes, you could manage a giant wad of patch in quilt too, but people
>>> tend not to. The workflow of quilt really pushes people into
>>> maintaining separate patches per distinct change. The workflow for
>>> a DVCS does not, which can be a bit of a problem.
>> Err. I am not sure what you consider a work-flow for a distributed
>> version control system like arch or git; but the common themes that
>> have emerged on the pkg-vcs mailing list, and the the talks Martin
>> and I gave at debconf, seems to indicate otherwise.
> That's exactly the problem. It doesn't have a single workflow; it's a
> general tool that you can use in many different ways, and you have to
> go to talks and read papers and study supplemental information to
> figure out how to do this in the way that works well.
But TIMTOWTDI is rarely an argument against a toolchain, in my
experience; or you'll have to argue against every general purpose
language out there.
And, really, you _don't_ have to read papers and go to talks. I
certainly did not -- there were no papers or talks around when I was
defining my work-flow.
> quilt, on the other hand, essentially enforces this workflow, since
> it's the only way in which quilt really works.
So quilt is the Python of the handle multiple lines of
development. Yuck. I much prefer the ruby/Perl approach.
>>> Also, quilt trivially juggles forty, sixty, or a hundred patches.
>>> I'm still a bit skeptical that a DVCS is going to handle that many
>>> branches and integration points as trivially as quilt does what it
>>> does, but I'm going to have to spend a fair number of hours playing
>>> with something like git before I'll have an informed opinion.
>>
>> I think you just need to go look at the Linux kernel source, and git,
>> and number and size of the different trees ythat are out there, and
>> how well git scales to those.
> Hm. This seems like a non sequitur to me. What is going on with the
> Linux tree is radically different than what I do with a Debian
> package. It's not really comparable; the workflow is completely
> different and in some cases essentially reversed.
Wow. I find this is not the case for me; when people come with
bug fixes, or changes in behaviour, for, say make or fvwm or flex; I
create a new feature branch, and make the integration work (the common
case requires no effort there).
From this point on, I never have to think about the feature when
new upstream versions come out.
> I need to be able to maintain a ton of small patches in an easily
> separable form that often will never be merged upstream, while doing
> the absolute minimum of work to pull those patches forward each time a
> new upstream version is released and still keeping each change
> separate. quilt does this perfectly. All explanations that I've seen
> so far on how to do this with git or arch are more complicated and
> slower than my workflow with quilt. With quilt, the typical upgrade
> is:
> * import new upstream source (done in the underlying VCS)
> * quilt push -a
> * repeat for each failing patch until no patches fail:
> - if quilt says patch was applied upstream, quilt delete the patch
> - otherwise, quilt push -f <patch>, resolve conflicts, quilt refresh
> * quilt pop -a
> * commit results
Heh. Here is my work flow.
* tla_load_dir (in the upstream branch)
* arch_upgrade (might have to run again, if I had to deal with
conflicts the first time)
Done.
Seems like much simpler than the quilt thingy.
> The normal case is no work at all. I literally don't have to do a
> thing except, if I choose, refresh patches that now have fuzz. The
> next most common case is there will be a few patches that upstream
> took that quilt will tell me are already applied and I just quilt
> delete them. Merging is rare. A DVCS might be somewhat better at
> that part, although most merges I run into are obvious to a human and
> impossible for a computer (variable renamings, API changes that change
> the function calls in affected code, that sort of thing).
The normal case is two simple commands on the command line.
> I don't have to update any other branches. It's basically doing,
> under the hood, pretty much what the DVCSes do, as I understand them,
> except that rather than have my working object be a branch, my working
> object is a patch. I LIKE that. I would much rather work on a patch
> than a branch because a patch is much easier to understand and can't
> ever get into an inconsistent state, and quilt lets me manipulate a
> patch in much the same way as a branch when I need to (add files to
> it, remove files from it, update with new changes, etc.).
Err, a patch requires me to think, and It can't just be compiled
automatically, for each branch. This is subjective. I find patches
far harder to deal with in practice than separate branches. I can
inspect the code straight out, rather than have to mentally manipulate
the code _and_ a patch. If I need a patch, the VCS can generate it, so
I don't lose out there either.
> There's no need to update metadata between branches. There's no need
> to inform branches about what patches have been merged, or manipulate
> the VCS metadata so that I can later merge branches without it trying
> to re-merge chnages that weren't conceptually part of the work I was
> doing on that branch.
Err, don't have to ever do much of that myself -- unless I am
cherry picking features from one branch and adding it to another, which
might be hard to do with quilt anyway.
> Similarly, if there's something new I have to fix, the workflow is:
> * quilt push -a (the branch switching equivalent)
> * quilt new <patch> (the equivalent of creating a new branch)
> * quilt edit <file>
> * quilt refresh (the commit equivalent)
> * quilt pop -a (the branch switching equivalent)
> It's the same number of steps as the VCS approach, and it creates the
> patch as an artifact so that I can easily review it without needing to
> run other commands to create it.
baz branch upstream
<<hack>>
commit
baz merge new-branch (in integration)
commit
Now, I can compile each ranch separately, read the code in
each branch, without having to mentally manipulate the code flow in my
head as I read a patch.
> If I were merging in multiple lines of development or patches from
> hundreds of other people and resolving conflicts between them, the
> DVCS advantages make a ton of sense, but that's not what I'm doing
> when I'm maintaining the average Debian package.
I don't think I want to use a tool that is only good for the bog
simple case, but would fail to scale, especially if it does not offer
much reduced effort, which does not seem to be the case here.
>> Where are we going with this (very interesting) discussion, anyway?
>> I seem to have lost track of the big picture road map/
> I'm continuing to object to adding wording to Policy that discourages
> people from using patch systems such as quilt or dpatch -- that's
> where this all started.
Oh, I agree there. Policy should ever say things about what
tools people can use (umm. I am tempted to ban vi and derivatives in
policy ... nah).
Policy should be able to specify that there should be a simple
mechanism to get to the sources that will be compiled, preferably
without having to trust code that needs to be run as privileged users
or is different from what will be run during the build process.
So, while we might not want policy to say that people should not
use quilt; we might want to be able to say that when I do dpkg -x
*.dsc; what I get is what is gonna be compiled.
manoj
--
It is impossible to defend perfectly against the attack of those who
want to die.
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: