You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Benjamin Mahler <be...@gmail.com> on 2015/05/15 02:07:09 UTC
Re: Scaling Proposal: MAINTAINERS Files
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 <be...@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 <to...@me.com> wrote:
>
> > +1 — thanks for this Ben!
> >
> > > On Feb 10, 2015, at 8:56 PM, Cody Maloney <co...@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.defelice@gmail.com>
> > > wrote:
> > >
> > >> +1 Tom/Adam
> > >>
> > >> --sent from my phone
> > >> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <ni...@mesosphere.io>
> > wrote:
> > >>
> > >>> +1
> > >>> Thanks for the write up Ben!
> > >>>
> > >>> On Tuesday, February 10, 2015, Dominic Hamon
> > <dhamon@twitter.com.invalid
> > >>>
> > >>> wrote:
> > >>>
> > >>>> Well, we should probably do that anyway :)
> > >>>> On Feb 10, 2015 2:25 AM, "Adam Bordelon" <adam@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 <yan@jxu.me <javascript:;>>
> > >>>> wrote:
> > >>>>>
> > >>>>>> Good point for "MAINTAINERS"
> > >>>>>>
> > >>>>>> --
> > >>>>>> Jiang Yan Xu <yan@jxu.me <javascript:;>> @xujyan <
> > >>>> http://twitter.com/xujyan>
> > >>>>>>
> > >>>>>> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <vinodkone@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 <
> > >>>>> dhamon@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.mahler@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+pkTiYvSzv1TQ@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-GhGCxEkQXwz063oUhPbrGBpvSa9ZsQTw@mail.gmail.com%3E
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=63uQ@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
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Scaling Proposal: MAINTAINERS Files
Posted by Niklas Nielsen <ni...@mesosphere.io>.
+1 - thanks for taking this on Ben!
On 14 May 2015 at 18:12, Adam Bordelon <ad...@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 <vi...@apache.org> wrote:
>
> > +1
> >
> > On Thu, May 14, 2015 at 5:07 PM, Benjamin Mahler <
> > benjamin.mahler@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 <
> > benh@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 <to...@me.com>
> > > wrote:
> > > >
> > > > > +1 — thanks for this Ben!
> > > > >
> > > > > > On Feb 10, 2015, at 8:56 PM, Cody Maloney <co...@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.defelice@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> +1 Tom/Adam
> > > > > >>
> > > > > >> --sent from my phone
> > > > > >> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <
> niklas@mesosphere.io>
> > > > > wrote:
> > > > > >>
> > > > > >>> +1
> > > > > >>> Thanks for the write up Ben!
> > > > > >>>
> > > > > >>> On Tuesday, February 10, 2015, Dominic Hamon
> > > > > <dhamon@twitter.com.invalid
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> Well, we should probably do that anyway :)
> > > > > >>>> On Feb 10, 2015 2:25 AM, "Adam Bordelon" <adam@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 <yan@jxu.me
> > > <javascript:;>>
> > > > > >>>> wrote:
> > > > > >>>>>
> > > > > >>>>>> Good point for "MAINTAINERS"
> > > > > >>>>>>
> > > > > >>>>>> --
> > > > > >>>>>> Jiang Yan Xu <yan@jxu.me <javascript:;>> @xujyan <
> > > > > >>>> http://twitter.com/xujyan>
> > > > > >>>>>>
> > > > > >>>>>> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <
> > > vinodkone@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 <
> > > > > >>>>> dhamon@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.mahler@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+pkTiYvSzv1TQ@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-GhGCxEkQXwz063oUhPbrGBpvSa9ZsQTw@mail.gmail.com%3E
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=63uQ@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
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Scaling Proposal: MAINTAINERS Files
Posted by Adam Bordelon <ad...@mesosphere.io>.
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 <vi...@apache.org> wrote:
> +1
>
> On Thu, May 14, 2015 at 5:07 PM, Benjamin Mahler <
> benjamin.mahler@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 <
> benh@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 <to...@me.com>
> > wrote:
> > >
> > > > +1 — thanks for this Ben!
> > > >
> > > > > On Feb 10, 2015, at 8:56 PM, Cody Maloney <co...@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.defelice@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> +1 Tom/Adam
> > > > >>
> > > > >> --sent from my phone
> > > > >> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <ni...@mesosphere.io>
> > > > wrote:
> > > > >>
> > > > >>> +1
> > > > >>> Thanks for the write up Ben!
> > > > >>>
> > > > >>> On Tuesday, February 10, 2015, Dominic Hamon
> > > > <dhamon@twitter.com.invalid
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> Well, we should probably do that anyway :)
> > > > >>>> On Feb 10, 2015 2:25 AM, "Adam Bordelon" <adam@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 <yan@jxu.me
> > <javascript:;>>
> > > > >>>> wrote:
> > > > >>>>>
> > > > >>>>>> Good point for "MAINTAINERS"
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Jiang Yan Xu <yan@jxu.me <javascript:;>> @xujyan <
> > > > >>>> http://twitter.com/xujyan>
> > > > >>>>>>
> > > > >>>>>> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <
> > vinodkone@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 <
> > > > >>>>> dhamon@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.mahler@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+pkTiYvSzv1TQ@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-GhGCxEkQXwz063oUhPbrGBpvSa9ZsQTw@mail.gmail.com%3E
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=63uQ@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
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Scaling Proposal: MAINTAINERS Files
Posted by Vinod Kone <vi...@apache.org>.
+1
On Thu, May 14, 2015 at 5:07 PM, Benjamin Mahler <be...@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 <be...@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 <to...@me.com>
> wrote:
> >
> > > +1 — thanks for this Ben!
> > >
> > > > On Feb 10, 2015, at 8:56 PM, Cody Maloney <co...@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.defelice@gmail.com>
> > > > wrote:
> > > >
> > > >> +1 Tom/Adam
> > > >>
> > > >> --sent from my phone
> > > >> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <ni...@mesosphere.io>
> > > wrote:
> > > >>
> > > >>> +1
> > > >>> Thanks for the write up Ben!
> > > >>>
> > > >>> On Tuesday, February 10, 2015, Dominic Hamon
> > > <dhamon@twitter.com.invalid
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>> Well, we should probably do that anyway :)
> > > >>>> On Feb 10, 2015 2:25 AM, "Adam Bordelon" <adam@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 <yan@jxu.me
> <javascript:;>>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>>> Good point for "MAINTAINERS"
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Jiang Yan Xu <yan@jxu.me <javascript:;>> @xujyan <
> > > >>>> http://twitter.com/xujyan>
> > > >>>>>>
> > > >>>>>> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <
> vinodkone@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 <
> > > >>>>> dhamon@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.mahler@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+pkTiYvSzv1TQ@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-GhGCxEkQXwz063oUhPbrGBpvSa9ZsQTw@mail.gmail.com%3E
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=63uQ@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
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>