+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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
