+1 On Thu, May 14, 2015 at 5:07 PM, Benjamin Mahler <benjamin.mah...@gmail.com> wrote:
> After stepping back and giving time for everyone to mull it over, and > having discussed it further with many of you, I wanted to bring the > discussion back to the list. The motivation remains the same, but I propose > two changes to the approach: > > (1) We use maintainers without any process requirement. That is, when > contributors are unsure who to send reviews to, maintainers provides a way > for them to engage with committers who have interest, experience, and a > long-term perspective on the relevant component. For committers, we will > trust them to use their judgement for when to engage with maintainers. > There is no "sign off" requirement or tooling enforcement related to this. > Taking our aversion of "OWNERS" further, many of us discussed how > privilege-based "sign offs" go against the Apache Way and can go awry in > the long term. For those that weren't present, the Spark maintainers > proposal thread here captures the concerns: > http://markmail.org/thread/vdqfdnfjwhvd46ry > > (2) Rather than adding a hierarchical file structure, we document > maintainers by "component" (e.g. framework API, containerization (external, > docker, mesos (network isolator, ...)), stout, libprocess, master, slave, > zookeeper, replicated log, webui, ...), ideally having a close relationship > to JIRA components. The maintainers can be documented in a table alongside > contribution / committer guidelines on our website. I think this will be > clearer than splitting it across files in our source filesystem, and isn't > tied to the file layout of our code. > > I will be proposing documentation soon based on this updated approach: > https://issues.apache.org/jira/browse/MESOS-2737 > > Please chime in with your feedback! > Ben > > On Wed, Feb 25, 2015 at 9:16 AM, Benjamin Hindman <b...@eecs.berkeley.edu> > wrote: > > > I had chatted with BenM and Vinod pretty extensively about this and am a > > +1. > > > > BenM: can you confirm how this interacts with the Apache by-laws? > > > > On Sat, Feb 14, 2015 at 10:25 AM, Till Toenshoff <toensh...@me.com> > wrote: > > > > > +1 — thanks for this Ben! > > > > > > > On Feb 10, 2015, at 8:56 PM, Cody Maloney <c...@mesosphere.io> > wrote: > > > > > > > > +1 > > > > > > > > It would be nice if there was way to specify things like "build > system > > > > changes" which are different than just adding/removing a single file. > > But > > > > probably that level of enforcement isn't worth the effort it would > take > > > to > > > > add. > > > > > > > > On Tue, Feb 10, 2015 at 8:56 AM, James DeFelice < > > > james.defel...@gmail.com> > > > > wrote: > > > > > > > >> +1 Tom/Adam > > > >> > > > >> --sent from my phone > > > >> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <nik...@mesosphere.io> > > > wrote: > > > >> > > > >>> +1 > > > >>> Thanks for the write up Ben! > > > >>> > > > >>> On Tuesday, February 10, 2015, Dominic Hamon > > > <dha...@twitter.com.invalid > > > >>> > > > >>> wrote: > > > >>> > > > >>>> Well, we should probably do that anyway :) > > > >>>> On Feb 10, 2015 2:25 AM, "Adam Bordelon" <a...@mesosphere.io > > > >>>> <javascript:;>> wrote: > > > >>>> > > > >>>>> +1 on MAINTAINERS over OWNERS, and the rest of the proposal thus > > far. > > > >>>>> Also +1 on "Merit is not about quantity of work, it means doing > > > >> things > > > >>>> the > > > >>>>> community values in a way that the community values." > > > >>>>> I will, however, echo Tom's concern that we may need to break up > > > >>>> master.cpp > > > >>>>> and slave.cpp if we want fine-grained maintainers of > subcomponents > > of > > > >>>>> either. > > > >>>>> > > > >>>>> On Mon, Feb 9, 2015 at 1:47 PM, Yan Xu <y...@jxu.me > <javascript:;>> > > > >>>> wrote: > > > >>>>> > > > >>>>>> Good point for "MAINTAINERS" > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Jiang Yan Xu <y...@jxu.me <javascript:;>> @xujyan < > > > >>>> http://twitter.com/xujyan> > > > >>>>>> > > > >>>>>> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone < > vinodk...@gmail.com > > > >>>> <javascript:;>> wrote: > > > >>>>>> > > > >>>>>>> I like MAINTAINERS because it sounds less authoritative than > > > >>> OWNERS. > > > >>>>>>> > > > >>>>>>> FWIW, maintainers is also a well understood and well used term > > > >>> (e.g: > > > >>>>>>> https://www.kernel.org/doc/linux/MAINTAINERS, > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-AddingMaintainerInformation > > > >>>>>>> ) > > > >>>>>>> > > > >>>>>>> On Sun, Feb 8, 2015 at 10:40 AM, Dominic Hamon < > > > >>>>> dha...@twopensource.com <javascript:;>> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> Yes, great. > > > >>>>>>>> > > > >>>>>>>> Why not use OWNERS as it is already in use internally at > > > >> Twitter, > > > >>>> at > > > >>>>>>>> Google, in Chromium, and tooling already supports that as an > > > >>>> implicit > > > >>>>>>>> standard? > > > >>>>>>>> On Feb 8, 2015 2:52 AM, "Benjamin Mahler" < > > > >>>> benjamin.mah...@gmail.com <javascript:;> > > > >>>>>> > > > >>>>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>>> Hi all, > > > >>>>>>>>> > > > >>>>>>>>> I have been chatting with a few committers and we'd like to > > > >>>>> consider > > > >>>>>>>> adding > > > >>>>>>>>> the concept of MAINTAINERS files to coincide with our > > > >>> "shepherds" > > > >>>>>>>> concept, > > > >>>>>>>>> introduced here: > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3ccafeoqnwjibkayurkf0mfxve2usd5d91xpoe8u+pktiyvszv...@mail.gmail.com%3E > > > >>>>>>>>> > > > >>>>>>>>> Please take a moment to read that thread and its responses > > > >> here > > > >>>> in > > > >>>>>>> which > > > >>>>>>>>> maintainers are alluded to: > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3cca+a2mtvc61-3idxtm-ghgcxekqxwz063ouhpbrgbpvsa9zs...@mail.gmail.com%3E > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=6...@mail.gmail.com%3E > > > >>>>>>>>> > > > >>>>>>>>> *Motivation:* > > > >>>>>>>>> > > > >>>>>>>>> To re-iterate from that thread, many companies rely on Mesos > > > >> as > > > >>>> the > > > >>>>>>>>> foundational layer of their software infrastructure stack. > > > >> Much > > > >>>> of > > > >>>>>> the > > > >>>>>>>>> success of Mesos can be attributed to our focus on quality > > > >>> (code > > > >>>>> that > > > >>>>>>> is > > > >>>>>>>>> simple / easy to read and understand, high attention to > > > >> detail, > > > >>>>>>> thorough > > > >>>>>>>>> reviewing, good testing practices, managing technical debt, > > > >>>>> learning > > > >>>>>>> from > > > >>>>>>>>> each other, etc). > > > >>>>>>>>> > > > >>>>>>>>> As the community of contributors has grown, it's become > > > >>>>> increasingly > > > >>>>>>>>> difficult to ensure that people are able to find reviewers > > > >> with > > > >>>>>>>> experience > > > >>>>>>>>> in specific areas of the project. Good contributions often > > > >> fall > > > >>>>>> through > > > >>>>>>>> the > > > >>>>>>>>> cracks as a result of the lack of clarity around this. > > > >>>>>>>>> > > > >>>>>>>>> We would like to ensure that reviewers with context and a > > > >>>> long-term > > > >>>>>>>> outlook > > > >>>>>>>>> on the particular area of the code are involved in providing > > > >>>>>> feedback. > > > >>>>>>> It > > > >>>>>>>>> can be difficult for a contributor to consider the > > > >> implications > > > >>>> of > > > >>>>>>> their > > > >>>>>>>>> change, when they are looking to get a bug fixed or a feature > > > >>>>>>> implemented > > > >>>>>>>>> before the next release or the end of a sprint. > > > >>>>>>>>> > > > >>>>>>>>> We'd like to be able to add more and more committers as the > > > >>>>> community > > > >>>>>>>>> grows, and incentivize them to become responsible maintainers > > > >>> of > > > >>>>>>>> components > > > >>>>>>>>> as they become more involved in the project. > > > >>>>>>>>> > > > >>>>>>>>> *MAINTAINERS file system:* > > > >>>>>>>>> > > > >>>>>>>>> In order to ensure we can maintain the quality of the code as > > > >>> we > > > >>>>>> grow, > > > >>>>>>>> we'd > > > >>>>>>>>> like to propose adding an MAINTAINERS file system to the > > > >> source > > > >>>>> tree. > > > >>>>>>>>> > > > >>>>>>>>> From the chromium mailing list (s/OWNERS/MAINTAINERS/): > > > >>>>>>>>> > > > >>>>>>>>> *"A MAINTAINERS file lives in a directory and describes (in > > > >>>> simple > > > >>>>>> list > > > >>>>>>>>> form) whose review is required to commit changes to it. > > > >>>>>> MAINTAINERShip > > > >>>>>>>>> inherits, in that someone listed at a higher level in the > > > >> tree > > > >>> is > > > >>>>>>> capable > > > >>>>>>>>> of reviewing changes to lower level files.* > > > >>>>>>>>> > > > >>>>>>>>> *MAINTAINERS files provide a means for people to find > > > >> engineers > > > >>>>>>>> experienced > > > >>>>>>>>> in developing specific areas for code reviews. They are > > > >>> designed > > > >>>> to > > > >>>>>>> help > > > >>>>>>>>> ensure changes don't fall through the cracks and get > > > >>> appropriate > > > >>>>>>>> scrutiny. > > > >>>>>>>>> MAINTAINERShip is a responsibility and people designated as > > > >>>>>> MAINTAINERS > > > >>>>>>>> in > > > >>>>>>>>> a given area are responsible for the long term improvement of > > > >>>> that > > > >>>>>>> area, > > > >>>>>>>>> and reviewing code in that area."* > > > >>>>>>>>> > > > >>>>>>>>> This would be enforced via our review tooling > > > >> (post-reviews.py > > > >>> / > > > >>>>>>>> reviewbot, > > > >>>>>>>>> apply-review.py), and a git commit hook if possible. > > > >>>>>>>>> > > > >>>>>>>>> There would be a process for becoming a maintainer, the > > > >> details > > > >>>> of > > > >>>>>>> which > > > >>>>>>>> we > > > >>>>>>>>> will clarify in a follow up. I’m thinking it will require an > > > >>>>> existing > > > >>>>>>>>> maintainer proposing a candidate to become a maintainer based > > > >>> on > > > >>>>>> merit. > > > >>>>>>>>> Merit is not about quantity of work, it means doing things > > > >> the > > > >>>>>>> community > > > >>>>>>>>> values in a way that the community values. > > > >>>>>>>>> > > > >>>>>>>>> As part of this, we would be documenting qualities we look > > > >> for > > > >>> in > > > >>>>>>>>> committers and maintainers. > > > >>>>>>>>> > > > >>>>>>>>> *Feedback:* > > > >>>>>>>>> > > > >>>>>>>>> The goal with this is to be even more inclusive than we are > > > >>> today > > > >>>>>> while > > > >>>>>>>>> maintaining the quality of our code and design decisions. > > > >>>>>>>>> > > > >>>>>>>>> I'm a +1 for this approach, and I would like to hear from > > > >>> others. > > > >>>>>> What > > > >>>>>>> do > > > >>>>>>>>> you like about this? What are potential concerns? Much of > > > >> this > > > >>>> was > > > >>>>>>>> thought > > > >>>>>>>>> about in terms of how to further the following of the Apache > > > >>> Way > > > >>>>> for > > > >>>>>>>> Mesos, > > > >>>>>>>>> any concerns there? Take your time to mull this over, your > > > >>>> feedback > > > >>>>>>> would > > > >>>>>>>>> be much appreciated. > > > >>>>>>>>> > > > >>>>>>>>> If this does sound good to everyone at a high level, I will > > > >>>> follow > > > >>>>> up > > > >>>>>>>> with > > > >>>>>>>>> further discussion to formalize this, and I’ll work to > > > >> document > > > >>>> and > > > >>>>>>>>> implement it. > > > >>>>>>>>> > > > >>>>>>>>> Ben > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > >
