[U-Boot] RFC - PatchTrack Specification

[U-Boot] RFC - PatchTrack Specification

[Graeme Russ]

Hi All,

Here's a quick-and-dirty specification for a patch tracking tool...

PatchTrack is designed to help alleviate some of the load from custodians
manging a email based work flow accepting patches from a large community
of contributors

Functionality:
 - Monitor an electronic mailing list, extracting patches as they are
   posted to the list
 - Group patchsets that are posted using x/y style numbering. The patches
   within the set are grouped under the 0/y patch
 - Run arbitrarily defined stand-alone sanity checks on each patch. For
   example, the 'checkpatch' script can be run to check that each incoming
   patch obeys the style rules of the project
 - Associate each patch with a git repository. Association is determined
   by tags in the patch subject header
 - Maintain the revision history of each patch
 - Maintain community comments sent to the mailing list for each patch
 - Collect Ack'd, Nack'd, Tested, etc. community feedback (the feedback
   tags are configurable)
 - Maintain a 'patch stack' of unapplied patches for each configure
   repository. The patch stack is maintained as a 'first in, first served'
   list of patches
 - Test that each patch stack applies to the HEAD of the associated git
   repository
 - Re-test that the patch stack applies whenever the HEAD of the
   associated git repository changes


Interface:
The primary interface to PatchTrack is emails extracted from a configured
mailbox.

PatchTrack also provides a web-based interface which allows a user to
visualise the patch stack for each repository. For each configured
repository, the web interface will display associated patches in
chronologically ordered rows. Each row is a single patch. patch sets
are grouped together using the timestamp of the fist patch. The following
information is displayed in each row:
 - Patch name/subject
 - Author
 - Number of received Ack, Nack, Tested, etc. feedbacks

The colour of each row indicates the 'quality' of the patch:
 - Red indicates the patch does not apply cleanly. Red patches are not
   actually in the patch stack but are displayed for completeness
 - Orange indicates that the patch does apply but has failed one or more
   of the configured sanity checks
 - Yellow indicates that the patch applies and passed all configured sanity
   checks
 - Green indicates that the patch has been accepted by a maintainer. All
   green patches are placed at the top of the stack (i.e. they are always
   applied first) in order of acceptance (not submission order)
 - White indicates that the patch has been applied to the repository

Clicking on any row will expand the row (clicking again will collapse the
row). An expanded row displays the following information:
 - Ack'd, Nack'd, Tested, etc. tags
 - Sanity check results
 - Patch apply result
 - Comments
 - Patch body

The web interface will provide an authenticated login. When a maintainer of
a repository is logged in, they can:
 - Reject a patch, removing it from the patch stack entirely
 - Accept a patch. When a patch is accepted, PatchTrack will check that the
   patch applies cleanly to the HEAD of previously accepted patches
 - Apply the top 'x' accepted patches the git repository
 - Purge applied patches from PatchTrack

[U-Boot] RFC - PatchTrack Specification

[Marek Vasut]

Dear Graeme Russ,

> Hi All,
> 
> Here's a quick-and-dirty specification for a patch tracking tool...

And here comes our RMK of U-Boot world, the philosopher ;-)

> PatchTrack is designed to help alleviate some of the load from custodians
> manging a email based work flow accepting patches from a large community
> of contributors
> 
> Functionality:
>  - Monitor an electronic mailing list, extracting patches as they are
>    posted to the list
>  - Group patchsets that are posted using x/y style numbering. The patches
>    within the set are grouped under the 0/y patch
>  - Run arbitrarily defined stand-alone sanity checks on each patch. For
>    example, the 'checkpatch' script can be run to check that each incoming
>    patch obeys the style rules of the project
>  - Associate each patch with a git repository. Association is determined
>    by tags in the patch subject header
>  - Maintain the revision history of each patch
>  - Maintain community comments sent to the mailing list for each patch
>  - Collect Ack'd, Nack'd, Tested, etc. community feedback (the feedback
>    tags are configurable)
>  - Maintain a 'patch stack' of unapplied patches for each configure
>    repository. The patch stack is maintained as a 'first in, first served'
>    list of patches
>  - Test that each patch stack applies to the HEAD of the associated git
>    repository

But if you stack the patches, they tend to interfere with each other ... so you 
might also want to try applying them in the order they arrived or something. But 
hey, it's 6:20 am in here, don't expect too constructive comment now.

>  - Re-test that the patch stack applies whenever the HEAD of the
>    associated git repository changes

Yup, sounds very nice and about what we need. Leaving out the build testing was 
good idea, though working it in later might be necessary.

> 
> Interface:
> The primary interface to PatchTrack is emails extracted from a configured
> mailbox.

I told you, emails can be forged.

> PatchTrack also provides a web-based interface which allows a user to
> visualise the patch stack for each repository. For each configured
> repository, the web interface will display associated patches in
> chronologically ordered rows. Each row is a single patch. patch sets
> are grouped together using the timestamp of the fist patch. The following
> information is displayed in each row:
>  - Patch name/subject
>  - Author
>  - Number of received Ack, Nack, Tested, etc. feedbacks

Patchwork can be tweaked to do this, right?

> The colour of each row indicates the 'quality' of the patch:
>  - Red indicates the patch does not apply cleanly. Red patches are not
>    actually in the patch stack but are displayed for completeness
>  - Orange indicates that the patch does apply but has failed one or more
>    of the configured sanity checks
>  - Yellow indicates that the patch applies and passed all configured sanity
>    checks

Why not make it "yellow" -- patch has warnings ; "green" -- patch passed checks 
; <blue?> -- patch is frozen (aka. accepted)

>  - Green indicates that the patch has been accepted by a maintainer. All
>    green patches are placed at the top of the stack (i.e. they are always
>    applied first) in order of acceptance (not submission order)
>  - White indicates that the patch has been applied to the repository
> 
> Clicking on any row will expand the row (clicking again will collapse the
> row). An expanded row displays the following information:
>  - Ack'd, Nack'd, Tested, etc. tags
>  - Sanity check results
>  - Patch apply result
>  - Comments
>  - Patch body
> 
> The web interface will provide an authenticated login. When a maintainer of
> a repository is logged in, they can:
>  - Reject a patch, removing it from the patch stack entirely
>  - Accept a patch. When a patch is accepted, PatchTrack will check that the
>    patch applies cleanly to the HEAD of previously accepted patches
>  - Apply the top 'x' accepted patches the git repository
>  - Purge applied patches from PatchTrack

Mm mm ... I like this, do you plan to hack on it? :)

Best regards,
Marek Vasut

[U-Boot] RFC - PatchTrack Specification

[Wolfgang Denk]

Dear Graeme,

In message <CALButCK05e4VwWr3bzaSyBJiDNJD4OmQ+Szj=Ks2J747xgVusw@mail.gmail.com> you wrote:
> 
> Here's a quick-and-dirty specification for a patch tracking tool...

Thanks a lot.

I think this is worth for a depper discussion, and I would like to
track the information (and agreements / disagreements) we have on the
long list of items we have here.

I added the porposal as page to the U-Boot wiki:

	http://www.denx.de/wiki/U-Boot/ToolsPatchTracking

I propose to use this page to add updates as we go, hoping that this
will ripe over time, and finally (hopefully soon) result in the
fruits of an implementation.

Thanks!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I haven't lost my mind -- it's backed up on tape somewhere.