First impressions (long)

[James Westby]

On Fri Dec 11 22:12:41 +0000 2009 Barry Warsaw wrote:
> Hi all,
> 
> I think I've actually patched my first Ubuntu package, with much thanks to
> Colin and James W for their help.  Having done this from essentially no
> knowledge of how to do it, and no experience with the tools, James suggested I
> email this list with some feedback and suggestions.  Remember, I'm a n00b so
> be gentle because I have No Idea What I'm Talking About. :)

Hi Barry,

This is great feedback, thanks. It's invaluable to get the view from fresh
eyes.

> I had to learn a little bit of extra process to build
> the package the right way,

Could you say a little more about what these things were?

> So what did I do?  Here are the steps I took (minus some machinations to get
> debsign to DTRT):
> 
> * bzr init-repo system-config-lvm
> * cd system-config-lvm
> * bzr branch lp:ubuntu/system-config-lvm
> * bzr branch system-config-lvm 390423-ext4
> * cd 390423-ext4
> * (download patch from upstream tracker)
> * patch -p1 < patch.txt
> * dch -i
> * (add changelog entry)
> * debcommit
> * bzr commit --fixes lp:390423 --unchanged
> * bzr builddeb
> * (win!  or was it?)
> * (dpkg -i blah; test; confirm fix)
> * bzr push lp:~barry/ubuntu/lucid/390423-ext4
> * bzr lp-open
> * (submit merge proposal)

Great, this is pretty much how I want things to look, as it is very similar
to a patch to a typical project, rather than being completely different
as with the current process.

(Should we be more vocal about being able to use "bzr send" to submit
 code to LP? Are there drawbacks that mean you don't use it?)

> You probably saw immediately where I went wrong!  I didn't know anything about
> patch systems at this point, so I just committed my changes to the source tree
> in place.  Colin (politely and helpfully!) schooled me that I should have
> created a patch file instead, left the original source unchanged, and added my
> patch file to debian/patches/00list.  My diff should have included just the
> new .dpatch file, along with the changes to the changelog and 00list.
> 
> Instead of backing out my changes, I extracted them from the relevant
> revisions, doing something like this (at the time):
> 
> * bzr diff -r6.. | dpatch patch-template -p "ext4xfssupport" "blah" >
> debian/patches/ext4xfssupport.dpatch"

This is what we spoke about automating on IRC. It wouldn't be hard, but
may not be the best thing for long-term gain.

> I might almost say the experience was a delight! :)

Excellent. I'm glad it sounds like the patch system was the most painful
thing, as that's not my fault :-)

> Now, I might not be using the tools at all correctly, and may have just
> stumbled an a right-ish answer, but here are a few things I think could be
> added to bzr-builddeb to make fixing bugs in Ubuntu almost crazy easy.
> 
> * Use looms (or pipes I suppose, but I prefer looms over pipes).
> 
> Here's the way (I think) I'd organize my branch threads:
> 
> - review-comments
> - hack-the-source-code
> - dpatches
> - changelog
> - system-config-lvm
> 
> Thus the source package trunk is at the bottom thread.  At the top are the
> threads that actually change the source code in place.  This can sometimes be
> handy if you can/want to run the code right from there, as I did a few times
> since it's just Python and easily run in-place.  It's certainly way easier
> manage code this way for someone who's used to normal bzr development.
> 
> In the middle are the threads that pertain to package building.  The reason
> I'm putting them in the middle is because eventually I'm going to slice off
> the top two threads since they are not appropriate for sponsorship.  Actually,
> what I'm going to do is export the loom and push only the dpatches thread, so
> having the irrelevant local stuff at the top makes that easy.
> 
> I'm separating the changelog and dpatches threads though perhaps in practice
> they can be combined.  The important thing, and where I think bzr-builddeb
> could really shine, would be to generate the dpatches, and maybe even the
> changelog threads for me.
> 
> Imagine that I'm sitting in the hack-the-source-code thread and I'm now ready
> to build my package for local testing.  I've already committed several
> revisions to the source code in-place, so why couldn't bzr automatically run
> 'dch -i' and generate the changelog thread?  It could take its input out of
> the commit messages (with command line override).
> 
> Why too couldn't bzr generate the dpatches for me?  It /knows/ that it needs
> to diff hack-the-source-code against system-config-lvm so it could
> automatically remove any changes in the changelog or dpatches threads to
> generate the .dpatch file.

I find it interesting you propose threads for organising your changes on
top of the packaging. Usually when we discuss looms, it is for replacing
the patch system entirely, so that the branches hosted on LP would be looms
themselves. The bottom thread is then the pristine upstream code. I guess
starting from that would aid you, as you could just add a new thread and
do your stuff, without worrying about the patch system or lack thereof?

It does make me wonder about the interaction between the desire to use
threads for organsing the changes from upstream, and also for organising
your local changes to the package. Would you feel comfortable working
in a loom where you would be modifying an existing thread, or adding
a thread for a new patch (plus modifying a packaging thread for the
changelog?) Would you want to be able to e.g. have a "review-comments"
thread? Does loom allow you to do that while making it easy to collapse
your changes back for presentation to the world?

Thanks,

James