neilk at wikimedia
Dec 21, 2011, 12:03 PM
Post #6 of 8
Definitely a good idea.
Re: Code review thoughts: module reviewers
[In reply to]
I'd like to further suggest that reviewers for particular parts of the
codebase ought to be listed somewhere publicly. Rightly or wrongly a lot
of people want guidance before embarking on a project to fix something.
So if somebody has an idea or a patch, they don't have to do the
"anyone? anyone? Bueller?" thing in bugzilla or wikitech-l. These
reviewers could evolve into mentors, if they are so inclined.
When we have git, maybe we can even automate this with pull requests...
Of course we should still allow it to be as flexible as possible. It
should be easy to re-assign a change to someone else's queue. No one
person should be able to block commits.
On 12/20/11 3:01 PM, Brion Vibber wrote:
> We've sorta informally done things were revisions have gotten tagged for
> some particular person's review as an area of specialty, but we've never
> really had formal division of labor among separate parts -- nothing for
> instance that can be used to automatically queue things up for particular
> peoples' inboxes for timely review.
> Often, little things are suitable for many people to look at, but major
> subsystem refactorings -- like the landing of Aaron's file backend changes
> -- really are specialized and need to be looked over by somebody who's a
> specialist, rather than just whoever gets around to looking it over.
> I'd like us to seriously consider having primary reviewers for various code
> modules, so things like this get handled asap and don't end up falling
> through the cracks -- big changes, and small confusing changes ;) -- should
> get pretty consistently treated.
> Projects like Firefox or the Linux kernel tend to have responsible parties
> for various modules, who either manage ingestion of patches through the
> source control or issue tracker and do testing, review, feedback, and
> eventual merging. I think we would do well to emulate this a little more
> explicitly than we do today, especially if we're trying to keep from having
> an ever-growing review backlog.
> Thoughts? Volunteers?
> -- brion
> Wikitech-l mailing list
> Wikitech-l [at] lists
Neil Kandalgaonkar ( <neilk [at] wikimedia>
Wikitech-l mailing list
Wikitech-l [at] lists