mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominic Hamon <dha...@twitter.com.INVALID>
Subject Re: Scaling Proposal: MAINTAINERS Files
Date Tue, 10 Feb 2015 15:24:40 GMT
Well, we should probably do that anyway :)
On Feb 10, 2015 2:25 AM, "Adam Bordelon" <adam@mesosphere.io> 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> wrote:
>
> > Good point for "MAINTAINERS"
> >
> > --
> > Jiang Yan Xu <yan@jxu.me> @xujyan <http://twitter.com/xujyan>
> >
> > On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone <vinodkone@gmail.com> 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>
> > > 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
> >
> > > > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message