On Mon 15 Jul 2013 11:43:05 AM PDT, Boris Zbarsky wrote:
On 7/15/13 2:36 PM, Chris Peterson wrote:
If reviewee submits a new version of (say) patch 1 of 6, should they:
* attach patch 1 version 2
* an interdiff between patch 1 version 1 and 2
Yes, to both.
Bleagh. All of this points to an annoying gap in our tooling. Can't we
get a multiheaded repo of some sort that we can push this stuff to, to
avoid the need for these contortions? I guess it would probably suffer
the same perf death as the try repo, unless we prune out heads from
resolved (or shipped?) bugs.
Which file would be r+'d for review?
Generally whatever will actually get checked in.
Even for the case of dependent patches (ones with separate parts that
cannot be landed together, but are usefully split up for review)? In
that case, I'd expect only the individual patches to carry the r+. I
have occasionally uploaded a new rollup patch and marked it r+ myself
in these situations, but usually I just ignore or obsolete the rollup
when it's no longer needed for reviewers or fuzzers. Even when it's the
rollup that I land. Perhaps that's wrong of me, but it seems like the
patches attached to bugs and the patches that actually land aren't very
well correlated in our current setup anyway. I regard bug attachments
as totally review-focused, not commit-focused. The info about what was
committed is communicated (accurately) via the landing revision urls.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
