Differences between revisions 16 and 30 (spanning 14 versions)
Revision 16 as of 2014-05-02 05:53:47
Size: 2282
Comment: fix typo
Revision 30 as of 2016-03-08 14:30:38
Size: 2794
Comment: add boilerplate of developer page
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma section-numbers 2

<<Include(A:style)>>
<<Include(A:dev)>>
Line 5: Line 10:
<<TableOfContents>>
Line 28: Line 34:
   * Documentation augmented an updated    * Documentation augmented and updated
Line 45: Line 51:
Some people are blessed to accept patches and push them to a repo where Matt Mackall ultimatly pull from. Some people are blessed to accept patches and push them to a repo where Matt Mackall ultimately pulls from.
Line 55: Line 61:
 * you can get the patches files directly from http://hgpatches.durin42.com/patches/<node> Appropriate hg alias would be:

  {{{
[alias]
getpatch=import --partial --obsolete http://hgpatches.durin42.com/patches/$1
}}}
Line 58: Line 71:
hg debugobsolete $EMAIL_NODE $NEW_NODE hg import --partial --obsolete <patches>:
Line 60: Line 73:
Line 76: Line 90:
 * Collection of script  * [[http://42.netv6.net/reviewtools/|Collection of script]]
Line 78: Line 92:
 * [[http://www.selenic.com/inbox|Matt Mackall Inbox Metrix]] (nb email, nb patches, oldest email (in day))  * Various data collection [[http://review.octopoid.net/]] (STALED)

 * Matt Mackall Inbox [[http://www.selenic.com/inbox|Metrix (nb email, nb patches, oldest email (in day))]] and [[http://www.selenic.com/inflight|Content]].

----
CategoryDeveloper

{i} This page does not meet our wiki style guidelines. Please help improve this page by cleaning up its formatting.

Note:

This page is primarily intended for developers of Mercurial.

Patch Review Process

This page explains the Mercurial patch review process and how (anyone) can help.

1. Generic Fact

2. Simple Review Checklist

  • The patch should conform to the ContributingChanges bullet list.

    • Quick reminder of important things:
    • commit message format,
    • Patch does one and only one thing,
    • Change is tested
    • Documentation augmented and updated
    • (all the other things in the list)
  • You understand the change
  • The change seems correct
  • The change seems efficient

If any concerns raised, reply to the email asking questions.

If everything sounds good, reply to the email too. Just state it looks good to you.

3. Accepters Review Checklist

Some people are blessed to accept patches and push them to a repo where Matt Mackall ultimately pulls from.

Here is another check list for them

  • Run check code on all patches
  • Run the whole test suites
  • Reply to the list saying that you took care of the patch
  • you can get the patches files directly from http://hgpatches.durin42.com/patches/<node> Appropriate hg alias would be:

    • [alias]
      getpatch=import --partial --obsolete http://hgpatches.durin42.com/patches/$1
  • Make sure you created obsolescence marker between the node in the patch and the one you created, e.g.
    • hg import --partial --obsolete <patches>:
  • use the drophack extension if you need to drop a changeset you queued

  • Rebase your queue on top of main's @

  • Move @ with the changeset you pushed.

  • Update Patchwork once you have pushed

4. Review Tooling


CategoryDeveloper

ReviewProcess (last edited 2022-10-12 15:53:35 by AugieFackler)