There are indeed a lot of edge cases and concerns, but this is off-topic for this thread now. We're still in early stages here, as some more groundwork has to be laid. We'll be coming back to this after some crucial Phabricator/Lando work has landed. It's something we're quite interested in and has been a long time coming.
Mark On Thu, Jul 5, 2018 at 3:27 PM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 05/07/2018 18:19, Mark Côté wrote: > >> I sympathize with the concerns here; however, changing the default would >> be a very invasive change to Phabricator, which would not only be complex >> to implement but troublesome to maintain, as we upgrade Phabricator every >> week or two. >> >> This is, however, something we can address with our new custom >> commit-series-friendly command-line tool. We are also working towards the >> superior solution of automatically selecting reviewers based on module >> owners and peers and enforcing this in Lando. >> > > Automatically selecting reviewers sounds like a huge improvement, > particularly for people making changes who haven't yet internalised the > ownership status of the files they are touching (notably any kind of > first-time or otherwise infrequent contributor to a specific piece of > code). So I'm very excited about this change. > > That said, basing it on the list of module owners & peers seems like it > may not be the right decision for a number of reasons: > > * The number of reviews for a given module can be very large and being > unconditionally selected for every review in a module may be overwhelming. > > * The list of module owners and peers is not uniformly well maintained (in > at least some cases it suggests that components are owned by people who > have not been involved with the project for several years). Although this > should certainly be cleaned up, the fact is that the current data is not > reliable in many cases. > > * Oftentimes there is substructure within a module that means that some > people should be reviewers in certain files/directories but have no > knowledge of other parts. > > * It usually desirable to have people perform code review for some time as > part of the process of becoming a module owner or peer. > > A better solution would be to have in-tree metadata files providing > subscription rules for code review (e.g. a mapping of usernames to a list > of patterns matching files). Module owners would be responsible for > reviewing changes to these rules to ensure that automatic delegation > happens to the correct people. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
