#pragma section-numbers 2 <> <> = Patch Review Process = This page explains the Mercurial patch review process and how (anyone) can help. <> == Generic Fact == * Reviews happen on MailingLists#The_Mercurial-Devel_list and [[https://phab.mercurial-scm.org/|Phabricator]] * Contributors follow the ContributingChanges and send their patch(es) to the list * Reviews are just email replies to the emailed patch, or Phabricator comments * ``Everyone`` is welcome to do review == Simple Review Checklist == * The patch should conform to the ContributingChanges bullet list. * You understand the change * The change seems correct * The change seems efficient === For email patches === 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 in your reply. === For Phabricator patches === Comment on the web page. Feel free to use "Accept Revision" action even if you're not a core reviewer. If you want to comment without using a browser, follow steps on [[Phabricator]] and use "hg phabupdate". == Things we commonly miss == (we should probably move these recommendation in other page and just link to them) * Good 'topic'. (The part is the one before colon in the first line `topic: short desc`). It is unvaluable to sort thing out when scanning through commit, especially when building a release changelog. A common mistake is to pick a very general work like "commands". * Config section. All debatable/temporary/unsure-we-want-this config should go to the `[experimental]` config section. For other option, try to avoid adding a new section if we can't foresee more than one option in it and another pre-existing section would be a good fit. * Deprecation warning, if a major internal API get killed, encourage the preservation of the old version for 1 version with a deprecation warning (if it is easy to implement). This makes third party extensions maintainer life easier. == 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/ 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. {{{#!bash hg import --partial --obsolete : }}} * use the [[https://bitbucket.org/marmoute/mutable-history/src/98b5ac44a25913e546f4588dba5b7a1db39c82d4/hgext/drophack.py?at=default|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. == Review Tooling == * [[https://phab.mercurial-scm.org/|Phabricator]] * [[http://hgpatches.durin42.com/|The Patches Bot]] ([[http://hg.durin42.com/patchbot/|sources]]) * 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]]. == The Committers Group == Current list with push access to the [[https://www.mercurial-scm.org/repo/hg-committed/|hg-committed repository]] * Kevin Bullock * Augie Fackler * Matt Mackall * Yuya Nishihara * Martin von Zweigbergk * Gregory Szorc * Sean Farley * RyanMcElroy * Pulkit Goyal ---- CategoryDeveloper