mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Till Toenshoff <toensh...@me.com>
Subject Re: Scaling Proposal: MAINTAINERS Files
Date Sat, 14 Feb 2015 18:25:20 GMT
+1 — thanks for this Ben!

> On Feb 10, 2015, at 8:56 PM, Cody Maloney <cody@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
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message