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 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
