First impressions (long)

[Barry Warsaw]

On Dec 14, 2009, at 01:00 AM, James Westby wrote:

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

No problem!

>> 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?

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).

>(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.

>> * 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.

Right!

>> 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 :-)

:)

>
>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.

I didn't realize this was being discussed, but I think you're on the right
track.  The patch system just feels unnatural to me, who is admittedly much
more familiar with developing software with Bazaar than packaging for
Debian/Ubuntu.  It jives with my general opinion that patches are "dead" and
so '90's.  As a project leader, I actually hate patches and encourage everyone
to submit branches instead.

I hadn't thought about making the source package a loom and managing changes
through that entirely.  I like it.

>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?

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.

>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?

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.)

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.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20091214/ebb138bd/attachment.pgp