[loom:MERGE] fixing "main" part of setup.py
v.ladeuil+lp at free.fr
Wed Apr 2 08:46:02 BST 2008
>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:
aaron> Robert Collins wrote:
>> On Wed, 2008-04-02 at 10:04 +1100, Andrew Bennetts wrote:
>>> Aaron Bentley wrote:
>>>> It might be nice to increase the level of support; I think it's been
>>>> suggested that bzr send could attach a merge directive for every thread
>>>> in the loom to the message.
>>> I think I'd usually prefer one message per thread, rather than one message with
>>> all threads.
>> Thats what I want.
aaron> I guess it depends how you're using using threads.
Full agreement ;-)
aaron> In my work on Launchpad, I have use threads two ways:
aaron> - to separate various layers:
aaron> - database patch
aaron> - ORM updates
aaron> - UI
aaron> - to provide a diff against the last-reviewed version. I create a new
aaron> thread after each review.
I'm not sure I understand the rational here. Why not just adding
commits to the thread ? To keep the ability to modify your patch
*before* taking review comments into account ?
Do we need a 'split-thread-at-that-revision' loom command ?
aaron> This means that many of my threads (the ones due to
aaron> review) are closely-related, and I wouldn't want to
aaron> send them in different emails.
aaron> But for the same reason, I don't want to send them all at once.
For the faster-selftest loom, I encountered the following usage
1 - create a thread for every part I want to send a patch to the
list so that I can easily send patches and add more commits
for reviews (and this worked wonderfully so far),
2 - create some more threads for some features implementations
like 'pre-implementation-cleanup', 'implementation',
'post-implementation-cleanup'. This leaves the ability to add
more commits to any thread even if, in the end, there will
be two submissions only, the last two threads being combined
>> The bottom thread should usually be a proxy for the
>> submission branch, and not included (which can be detected
>> as its revision will be in the mainlines history already).
aaron> We could go further and not generate it for any thread
aaron> whose head is in the ancestry of the submit branch
I should be missing something here since that sounds too obvious
to not be the actual behavior 8-/
What I'd like for point 2 above is the ability to say: send a
bundle containing the changes up to thread X based on thread Y
(the default being that thread X is just above thread Y).
This may be achieved by adding a property to the thread saying
'this thread is a "submit" thread' (on by default ?), bzr send
can them build the patch from the current thread and includes
threads until the next 'submit' thread.
About sending one or several mails for a loom, I think there are
several use cases too.
Taking the faster-selftest loom example again, I have are three
1 - preparing the test suite (including fixing some previously
2 - define and use a new loader for --load-list to reduce load
3 - define a third loader (--id-starts-with) to address the
limitations of --load-list.
When I started working on 1, not being able to send patches
related to 2 and 3 was not a problem since some bugs were obvious
by themselves and the reviewers didn't need to see why I was
Then, I began some refactoring and showing 2 (may be 3), even as
work in progress may have help (like, for example, why I added a
'loader' parameter to multiply_tests_from_modules).
Now that 2 is ready to be delivered, I have the option to show
some preview of 3.
When 3 will be ready, well, the loom will be nearly a single
thread and about to die
So the use cases change during the loom use but roughly *my*
needs will be covered with:
- send a patch (single mail) for the current thread,
- send a patch for the current thread and includes preview
patches for 'these' threads,
- send a mail describing the loom and send followups to that mail
with patches for each thread starting at the current
thread. This will, for mail-thread (argh conflicting meanings
:-/) aware MUAs, create a mail-thread for the loom and a
mail-sub-thread for each patch.
Just throwing ideas,
More information about the bazaar