On 4/16/14, 10:02 AM, Bobby Holley wrote:
On Wed, Apr 16, 2014 at 9:47 AM, Robert Kaiser <ka...@kairo.at> wrote:
That's a good step. IMHO, often another good step is to mostly separate
every patch to its own bug (I know there are cases where it might not makes
sense, but often it does) so that individual chunks can be accounted for
separately in reviews, checkins, work-done reports, maybe even
verifications.
I think this is too much overhead to do for "every patch", and would
generally encourage people to make their patches too big. I tend to
optimize the size of my patches based on reviewability and bisectability,
and file different bugs based on what I expect to land in a single push.
I agree. Except I would like to go a step further and argue for one bug
per logical idea (as opposed to per push). Patches get bit rotted and
you can and should land them as soon as you get review. (If your patch N
of M doesn't leave the tree in a good state, then the patch is wrong.
Every commit in m-c - not just commits that were heads when they were
pushed - should be able to build. This helps ensure bisection works.)
I would prefer to accomplish this by shifting code review out of Bugzilla.
In my ideal world, code review is conducted in a non-Bugzilla code
review tool (like ReviewBoard). That code review tool intelligently
updates Bugzilla when appropriate (e.g. notifies Bugzilla when a review
references a specific bug). I like Phabricator's model here. See
https://secure.phabricator.com/T2230. The bug/task is nice and clean and
all the low-level review activity occurs in review land. You don't have
issues such as comments from multiple reviews/patches getting
interleaved, making discerning history of a single patch difficult. You
don't have reviews interfering with discussion of the issue or tracking
progress. Separation of concerns. This may sound like a radical idea,
but it's really not: GitHub reviews are already successfully employing
this approach (Bugzilla is updated when there is activity on GitHub).
As someone who wrote more patches in 2013 than all but ~10 other people
[1], I think Bugzilla overhead is real. We impose a lot of process
around landing patches. These are barriers to contribution (especially
compared to say GitHub pull requests) and I challenge the necessity of a
lot of these procedures and requirements. Once we have a better code
review story (in ReviewBoard [2]), I will be arguing for a scope
reduction in Bugzilla to eliminate some of the overhead to contribution.
That scope reduction will feature fewer total bugs to manage (reducing
Bugzilla overhead) and hopefully loosening the culture around "every
patch of significance requires a bug." But let's not discuss that until
ReviewBoard is in place and such a future is more realistic.
[1] https://gist.github.com/indygreg/9938270
[2] https://groups.google.com/forum/#!forum/mozilla-code-review
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
