First impressions (long)

[Barry Warsaw]

On Dec 14, 2009, at 10:41 PM, James Westby wrote:

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

Right.  These were issues I had to work through as a new Ubuntu developer
going about his first patch.  These questions are outside of the actual
mechanism to do the patch and thus part of what's common across both
approaches.

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

That's the direction I'd like to see.  It means that the normal tools I use to
develop the software are aware of the larger context and make things easy for
me.  Of course there's always a danger in being too simple or papering over
the details too much, such that any task outside the norm gets impossible to
accomplish.  But I think the right balance can be struck (you'd know whether
that's true much better than I).

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

I hadn't thought about putting the debian/ thread at the top, but your use
case makes perfect sense.  The reason I had put it right above the upstream
baseline thread is because then everything above it is patches, and you
wouldn't have to worry as much about where to put your new development
threads, or what to do with them once you collapse them into the thread you
want to push to the source branch.

But I think your use case is more important, though I wonder how easy it will
be to submit thread patches upstream out of order and independently, since
they'll have all the lower threads mixed in.  Maybe that's not a practical
problem though.

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

Yep.

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

I just think the current combine-thread command is a little too dangerous.  It
should never be possible to lose changes unless you're explicit about it.

-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/83cb502b/attachment-0001.pgp