Maintainers will come from the pool of committers. @vinodkone
> On Feb 11, 2015, at 6:47 AM, Alex Rukletsov <[email protected]> wrote: > > +1 for the proposal and for {master|slave}.cpp break up. > > Will there be any dependency between a maintainer and a committer? > >> On Tue, Feb 10, 2015 at 8:56 PM, Cody Maloney <[email protected]> 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 <[email protected]> >> wrote: >> >>> +1 Tom/Adam >>> >>> --sent from my phone >>>> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" <[email protected]> wrote: >>>> >>>> +1 >>>> Thanks for the write up Ben! >>>> >>>> On Tuesday, February 10, 2015, Dominic Hamon >> <[email protected] >>>> >>>> wrote: >>>> >>>>> Well, we should probably do that anyway :) >>>>> On Feb 10, 2015 2:25 AM, "Adam Bordelon" <[email protected] >>>>> <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 <[email protected] <javascript:;>> >>>>>> wrote: >>>>>> >>>>>>> Good point for "MAINTAINERS" >>>>>>> >>>>>>> -- >>>>>>> Jiang Yan Xu <[email protected] <javascript:;>> @xujyan < >>>>> http://twitter.com/xujyan> >>>>>>> >>>>>>> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <[email protected] >>>>> <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 < >>>>>> [email protected] <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" < >>>>> [email protected] <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+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 >>
