+1 - thanks for taking this on Ben! On 14 May 2015 at 18:12, Adam Bordelon <a...@mesosphere.io> wrote:
> SGTM. +1 on no special privileges for maintainers, trusting our committers, > and associating maintainers with (JIRA) components > > On Thu, May 14, 2015 at 5:23 PM, Vinod Kone <vinodk...@apache.org> wrote: > > > +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 > > > > > >>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > >
