mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Chen <tnac...@gmail.com>
Subject Re: Scaling Proposal: MAINTAINERS Files
Date Mon, 09 Feb 2015 19:58:23 GMT
+1
It makes sense as the next step to help ensure quality, like to see it
more documented as well.

Will be curious about the maintainer process and discussions.

Tim

On Tue, Feb 10, 2015 at 3:49 AM, Jie Yu <yujie.jay@gmail.com> wrote:
> +1
>
> On Fri, Feb 6, 2015 at 12:48 PM, Benjamin Mahler <benjamin.mahler@gmail.com>
> 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