mozilla :: #mozreview

12 Jul 2017
00:49kitcambridgehi! so, i'm wondering how mozreview decides to carry forward the review state for commits
00:49kitcambridgespecifically, if i have a single commit/patch attached to a bug that has r+
00:50kitcambridgeand i split that commit in two, with a "pre" part that i want to request review on
00:51kitcambridgewill it correctly carry forward the r+ on the second commit? (the commit message and MozReview-Commit-ID are the same)
00:53kitcambridgeor will it assume the first part is a new revision for what i've already posted, morph what's already attached (and r+ed) into the first part, and treat the second part as a new patch?
00:53* kitcambridge hopes that explanation makes sense
01:07mcotekitcambridge: if you split one commit into two, one of those commits won't have the r+
01:07mcoteI *think* the one with the same mozreview-id should have it carried forward, but not the other (which would be assigned a new id)
01:08kitcambridgeright, makes sense. I want to make sure it's the right one :-)
01:08kitcambridgeand it doesn't try to reset r+ for what's already there (even though it's now the second commit, and the first one needs r+$
01:09mcoteflyingrub: yes, that is how it is designed at the moment. however you won't be able to use autoland to land it until you have the correct permission (L3 scm access) or the most revision has been granted review by someone with r+
01:09mcotekitcambridge: yeah the whole carry-forward thing is a bit of a mess mainly because there hasn't been any solid Mozilla policy to implement :)
01:09mcoteso we took a best-effort approach, heh
01:10mcotein the new autoland stuff launching with phabricator, though, we'll be moving towards whatever policy gets finalized (the discussion of which was started by mconnor a while ago but is in a bit of a limbo state due to us switching tools)
06:25pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/bdf9cf901d9b - byron jones - docs: add docs for servo-backout-pr
19:06pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/0f4b99579def - Gregory Szorc - mozautomation: support discovering and persisting Firefox releases (bug 1380176); r=glob
19:06pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/1be3bbf959eb - Gregory Szorc - ansible/hg-web: periodically run Firefox releases scraper (bug 1380176); r=glob
19:06pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/b9ff70b6b5e4 - Gregory Szorc - hgmo: display Firefox release info on hg.mo (bug 1380176); r=glob
19:39pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/e45bbf0cc3d7 - Gregory Szorc - ansible/hg-web: fixes to support firefox release scraper (bug 1380176)
19:44pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/87eb58be1986 - Gregory Szorc - ansible/hg-web: use consistent directory for release database file (bug 1380176)
20:12pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/384654c0c400 - Gregory Szorc - docs: document Firefox release info on hg.mozilla.org (bug 1380176)
20:17pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/e2a76332e036 - Gregory Szorc - docs: document development info for firefox releases
13 Jul 2017
No messages
   
Last message: 11 days and 20 hours ago