mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <vinodk...@gmail.com>
Subject Re: Scaling Proposal: MAINTAINERS Files
Date Sun, 08 Feb 2015 17:26:00 GMT
+1

@vinodkone

> On Feb 8, 2015, at 4:04 AM, Tom Arnfeld <tom@duedil.com> wrote:
> 
> This sounds really interesting Ben - I'm definitely +1 to the idea.
> 
> 
> 
> 
> The only question that comes up in my mind is, are files/areas of the code base segmented
enough at the moment for this to be useful?
> 
> 
> 
> --
> 
> 
> Tom Arnfeld
> 
> Developer // DueDil
> 
> 
> 
> 
> 
> (+44) 7525940046
> 
> 25 Christopher Street, London, EC2A 2BS
> 
> On Sun, Feb 8, 2015 at 10:52 AM, 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