[CT-NG] Patchwork workflow

["Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>]

Hello All!

On Sunday 11 November 2012 Yann E. MORIN wrote:
> Also, I'm now using pathwork to manage the patches that are sent to the
> list. For those interested, I'll detail my new workflow in a separate
> message (as a reply to this one). Globally, I'm very happy to be using
> patchwork, it has made things a bit easier to manage! :-)

As promised, here's a more detailed view on how I manage patches being
sent to the list.

Since about mid-September, the guys at OzLabs [0] have been kind enough to
host an instance of patchwork [1] for use by the crosstool-NG project [2].

Patchwork works as thus:

  - an email address is subscribed to the mailing list, for delivery to the
    patchwork user at OzLabs;

  - when it receives a mail, patchwork tries to see if there is a patch in it;

  - if there is a patch, it is stored in the patchwork DB, and made available
    via a web interface, or via an XMLRPC interface;

  - if there is no patch, but the mail is a reply to a patch, then it is
    stored in the patchwork DB, and it is possible to display the complete
    thread on the web interface; moreover, SoB-lines (sob, ack...) that
    appear in replies are automatically added to any patch when it is
    retrieved via the XMLRPC interface;

  - patches are attached a status: New, Accepted, Rejected, Under Review...
    it is thus easy to filter patches;

  - anyone can register to patchwork with their email, and then can set the
    status for the patches they sent.

So, here's the workflow I use to apply patches:

1- I read the mails in the list with my MUA, briefly review patches for
   obvious issues and comments.

2- I wrote a script that automatically grabs a patch from patchwork, and
   applies it as a new MQ patch in the current repository clone. In the
   process, it stores the patchwork ID and message ID in the commit log, as
   sob-like lines (you've started seing them on recent commits, I hope!).

3- I further review and test the patches. If I have more comments, I go back
   to my MUA, and further reply to the patch.

4- When a patch is good for upstream, I push it with an alias (pwpush) that:
  - pushes the changes upstream (with hg push)
  - scans the new commits for patchwork and/or message IDs
    - for each patchwork ID, updates the status to Accepted
    - for each message ID, sends a mail to the patch author, and any other
      recipient listed as SoB, Ack, Test, or Cc; the mails are also CCed to
      the list, you've probably seen some of them recently.

5- For patches that are not accepted, I manually change their status to an
   appropriate state, after I explain why on the list. Patches that are not
   fit are set to Rejected, patches that have seen a second round are marked
   as Superseded. I also from time to time set the status to "Changes
   Requested" or "Not Applicable", but that's rare.

Basically, I treat any status that is not 'New' as a terminal status, and
I only act on New patches. Here's the current status of the patchwork DB
after about three months of usage:

 42 Accepted
 17 Superseded
  9 New
  4 Rejected
  4 Changes Requested
  1 Not Applicable
 77 Total

Using patchwork has been a major improvement from my previous workflow, which
involved manually copying mails to a different mailbox, and skimming the list
for those patches I may have forgotten. Now, I can see at a quick glance, and
with a simple command, what patches have been left unattended, what they are
about, and what they look like.

Here's a typical session (outputs have been stripped for brevity):

  $ hg pwlist
  Available patches for project 'crosstool-ng':
  193156 New   fix eglibc-2.16 manual build

  $ hg pwview 193156 | colordiff
  [email-body aka commit-log, followed by colored patch,]
  [on stdout; a colored patch is very nice to work with!]

  $ hg pwqimport 193156
  retrieving patch...
  patch subject is: fix eglibc-2.16 manual build
  adding fix_eglibc-2.16_manual_build to series file

  $ hg qseries -sv
  0 A fix_eglibc-2.16_manual_build: fix eglibc-2.16 manual build

  # diff, build, test...

  $ hg qfinish fix_eglibc-2.16_manual_build

  $ hg pwpush
  pushing to [upstream url]
  remote: added 1 changesets with 1 changes to 1 files
  updating Patchwork ID(s) for cset #381356803e87:
    - 193156, done
  sending mail(s) for cset #381356803e87:
    - <886f1bbadce3c2a5ea07.1348202558@localhost.localdomain>, done

I'll be polishing my script in the next few days, and will make it available
for those interested.

I hope you found this little story interesting! ;-)

Regards,
Yann E. MORIN.

[0] http://ozlabs.org/
[1] http://jk.ozlabs.org/projects/patchwork/
[2] http://patchwork.ozlabs.org/project/crosstool-ng/

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq