[loom:MERGE] fixing "main" part of setup.py

[Vincent Ladeuil]

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

<slighty related>
Do we need a 'split-thread-at-that-revision' loom command ?
</slightly related>

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

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

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

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
main features:

1 - preparing the test suite (including fixing some previously
    hidden bugs),

2 - define and use a new loader for --load-list to reduce load
    time,

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

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,

     Vincent