+1 @vinodkone
> On Feb 8, 2015, at 4:04 AM, Tom Arnfeld <[email protected]> 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 > <[email protected]> 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
