[U-Boot] RFC - PatchTrack Specification (revised)

[Marek Vasut <marek.vasut@gmail.com>]

Dear Graeme Russ,

> A revised version of the spec (sorry, I would have used reply-to but
> something went amiss with gmail and I've lost the original)

How does it surprise me ... superawesome google imap just crashed on me like a 
week ago, I finished syncing my emails today ...

[...]

> Operation Sequence - New single stand-alone patch:
>  - Determine which git repository the patch is intended to be applied to
>  - Add the patch to the top of the 'patch stack' of the target repository
>    NOTE: Patches are placed in the patch stack in the order they are
>    received
>  - Run the configurable set of sanity checks on the raw patch. A typical
>    example is the checkpatch.pl script which checks the patch for
>    correct style
>  - Perform a dummy git-apply of the patch onto the HEAD of the target
>    repository with all patches already on the repositories 'patch stack'
>    applied
>  - Record the results of the sanity checks and git-apply against the patch

You might want to actually create an mbox of all these stacked patches so people 
can download and apply them and rebase their patches on top of them.

[...]

> Operation Sequence - Revised version of existing patch
>  - Remove existing patch from patch stack
>  - Insert new patch into patch stack at same location as the removed patch
>  - Run the configurable set of sanity checks on the raw patch. A typical
>    example is the checkpatch.pl script which checks the patch for
>    correct style
>  - Perform a dummy git-apply of the patch onto the HEAD of the target
>    repository with all patches already on the repositories 'patch stack'
>    applied

Yes? Maybe this should be applied at the place where the old patch was, rather 
than on top.

[...]

> Web Interface
> In addition to processing inbound emails, PatchTrack includes web interface
> which allows a user to:
>  - Visualise the state of the patch stack for a given repository
>     * Passed sanity checks
>     * Passed git-apply
>     * Acked
>     * Tested
>     * Committed
>    NOTE: The patch stack is displayed as a series of rows in a table - One
>    row per patch. The colour of the row can be configured for each patch
>    state. For example, 'Acked' might be blue and 'Committed' white

Why not make committed like ... lavender or something </jab> ? :)

[...]
The rest sounds quite cool.

Best regards,
Marek Vasut