First impressions (long)

[James Westby]

On Mon Dec 14 21:31:14 +0000 2009 Barry Warsaw wrote:
> I went through the traditional package building process first, so there were a
> number of things I had questions about, had to learn, and had to do.  For
> example, do I use a chroot or a VM?  (I chose VM.)  I had to learn about,
> install and play with pbuilder, vs. having all the build dependencies around.
> I had to learn about how to make sure I had the build dependencies installed.
> I had to learn about dch, debuild, and debdiff.
> 
> One of the problems I had was getting debuild and debsign to use the right
> key.  I have several private keys, but one preferred one.  That's set up as my
> default gpg key (in my gpg.conf file), but debbuild and debsign weren't
> picking it up.  Eventually, I discovered ~/.devscripts and all was right with
> the world.
> 
> I also had a number of questions about process, such as:
> 
> * How rigorous should my testing be?
> * How rigorous should my review of the patch be?
> * Should I verify the upstream patch in their vcs?
> * If it's patched upstream, should we just resync w/upstream version?
> * Should I just use the upstream patch and trust them?
> 
> Colin helped me work through those questions, and more or less confirmed that
> what I'd done is right (be diligent, test what you can, make sure the patch is
> sane, but don't spend forever on it).

These are important things for us to work on, but they aren't really things
to fix with bzr, so that's good information yet again.

> >(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?)
> 
> I think so, yes.  I'm familiar with 'bzr send' because of my Launchpad
> experience, so I'd prefer that.  The reason I didn't use it was because the
> wiki pages I was reading didn't suggest it, and I wanted to go through the
> process as close to the wiki instructions as possible.
> 
> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship
> 
> The main drawback to using 'bzr send' is that you have to set your Bazaar
> configuration variables up right for it to work correctly.  More defaults here
> to DTRT after the initial branch would help.

I agree.

> Exactly, that would be fantastic.  Does that mean I can ignore dch also?  I
> would love to be able to ignore dch and debcommit and just do everything from
> within bzr.

We can add "bzr dch" if that makes you feel better :-)

I'm working to make debcommit be unnecessary, by making the things it does
the defaults for a plain "bzr commit."

There is still value in changelog handling, but there may be room for
more polish on top. In particular, if we use looms then a way to commit,
"up-thread -a", and then add that commit message to the changelog with
an option to edit could make things much smoother.

> Let's say I'm going to fix a package whose source branch is a loom.  So I
> branch it locally and get the whole loom.  I think you're right that the
> pristine upstream code is in the bottom thread.  Above that is probably the
> thread that adds the debian stuff, including debian/changelog.  It's this
> thread I'd edit directly to add changelog entries.
> 
> Above that are threads for each of the patches applied to the upstream code.
> It might not be a bad idea to be able to "lock" these threads so they can't be
> changed or deleted, once they've been accepted.  ("Locking" a thread isn't
> currently possible.)

Normally we talk about the path threads being below the packaging thread, so
that a merge of them in to the upstream branch doesn't pull in the packaging
changes.

Also, I'm not sure locking is the right thing. You may want to edit an
existing thread, or even delete one. Making "bzr branch; hack" work would
be nice though, not requiring an "add-patch" type command to be inserted in
the middle.

> Now, when I go to fix a bug, I'm stacking my threads on top, and indeed I
> might have several threads which combined fixes the bug.  I'd even have a
> thread for "review-comments".  Since all the threads I'm creating locally to
> fix the bug are at the top, I think it would be pretty easy to combine them
> down to one i-just-fixed-your-bug thread when I was ready for it to be
> merged.   And it's easy enough to hop down to the changelog thread and
> up-thread back to my working code.
> 
> The only thing we're missing is the combine-and-drop-down command, meaning
> "combine the top three threads into the new patch thread".  bzr combine-thread
> isn't it -- I don't trust that command at all because I think it throws away
> everything in the thread when it gets rid of it.  combine-thread /could/ be
> that thing if it did a merge without losing the changed in the current thread,
> and would refuse to combine down past say the last locked thread.

I agree that this sort of command would be generally useful.

Thanks,

James