You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by Mu Li <mu...@gmail.com> on 2018/01/09 05:58:10 UTC
Module maintainers proposal
It has been a while for discussing having maintainers for individual
modules. A maintainer for a module will be the main person who reviews and
approves PRs contributed to that module.
Currently, some maintainers are listed in the file CODEOWNERS
<https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>:
# Owners of Apache MXNet
# Global owners
* @apache/mxnet-committers
# Owners of language bindings
R-package/* @thirdwing
scala-package/* @javelinjs
perl-package/* @sergeykolychev
# CMake owners
CMakeLists.txt @cjolivier01
cmake/* @cjolivier01
However, this list is incomplete. This document proposes how to partition
mxnet codes into modules and put tentative maintainers for each module.
- I tried to select the activate contributor who contributed most to the
module, not the new contributor who is going to work for it. But I may be
outdated.
- Code review is not easy. So maintainers may need help at the
beginning.
- Eric (@piiswrong) did most PR reviews, so I didn't put his name on
every module.
Any suggestion is welcome.
FrontendPYTHON: @szha
python/
R: @thirdwing @hetong007
R-package/
SCALA: @CodingCat @javelinjs
scala-package/
PERL@sergeykolychev
perl-package/
C++?
cpp-package/
MATLAB: DEPRECATE IT?
matlab/
AMALGAMATION: DEPRECATE IT?
amalgamation/
Backend@reminisce @eric-haibin-lin
include/
src/
Build@cjolivier01
docker/
docker_multiarch/
make/
Makefile
cmake/
CMakeLists.txt
setup-utils/
prepare_mkl.sh
Test@marcoabreu
tests/
Jenkinsfile
Doc & Website@kevinthesun
docs/
ExamplesNot sure, since we have a lot of contributors here. We probably
need to remove low quality examples and assign one maintainer for each of
the rest.
example/
ToolsNot sure as well, since we have a bunch of things there. Probably need
to the same thing as examples
tools/
plugin/
AppendixLines of codes added into each folder on the last two months:
Lines of codes added into example/
Lines of codes added into src/
Re: Module maintainers proposal
Posted by Isabel Drost-Fromm <is...@apache.org>.
Am 15. Januar 2018 04:59:19 MEZ schrieb Chris Olivier <cj...@gmail.com>:
>+1 for the line: # Anybody can add themselves
+1 to this line, maybe add that the project intends to use to codeowner function as a notification mechanism.
This can be very handy also for new committers trying to focus on one code area.
However I'm a bit surprised finding this line, as else thread I read that the intention is for codeowners to get more say in when a pr gets merged than other committers. Can someone elaborate on how that is supposed to play together with any committer being able to add themselves?
Also did people check the commits mailing list? For typical Apache projects this is where code changes get copied. (Much like typically issue tracker changes get copied to issues@).
Isabel
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Module maintainers proposal
Posted by sandeep krishnamurthy <sa...@gmail.com>.
+1
We need include this information about CODEOWNERS watchlist functionality
to the website and contributions section of the documentation.
Regards,
Sandeep
On Tue, Jan 16, 2018 at 12:15 AM, Sebastian Schelter <
ssc.open@googlemail.com> wrote:
> +1
>
> 2018-01-16 9:08 GMT+01:00 Isabel Drost-Fromm <is...@apache.org>:
>
> > Hi,
> >
> >
> >
> > Am 16. Januar 2018 01:40:48 MEZ schrieb Steffen Rochel <
> > steffenrochel@gmail.com>:
> > ># Anybody can add themselves or a team as additional contributors
> > ># to get notified about changes in a specific package.
> > ># See https://help.github.com/articles/about-teams how to setup teams.
> > >
> > >Hope we can adopt this approach.
> >
> > Once you run with that approach: As to my knowledge you are the first
> > project at Apache using the code owners function, it would be great if
> you
> > could track its usage and impact on your community in coming incubator/
> > board reports.
> >
> > When first mentioning it, make sure though to either point ppl to this
> > thread or explain its intended use to avoid running into a second wave of
> > warnings about things discussed here already.
> >
> > Isabel
> >
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >
>
--
Sandeep Krishnamurthy
Re: Module maintainers proposal
Posted by Sebastian Schelter <ss...@googlemail.com>.
+1
2018-01-16 9:08 GMT+01:00 Isabel Drost-Fromm <is...@apache.org>:
> Hi,
>
>
>
> Am 16. Januar 2018 01:40:48 MEZ schrieb Steffen Rochel <
> steffenrochel@gmail.com>:
> ># Anybody can add themselves or a team as additional contributors
> ># to get notified about changes in a specific package.
> ># See https://help.github.com/articles/about-teams how to setup teams.
> >
> >Hope we can adopt this approach.
>
> Once you run with that approach: As to my knowledge you are the first
> project at Apache using the code owners function, it would be great if you
> could track its usage and impact on your community in coming incubator/
> board reports.
>
> When first mentioning it, make sure though to either point ppl to this
> thread or explain its intended use to avoid running into a second wave of
> warnings about things discussed here already.
>
> Isabel
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>
Re: Module maintainers proposal
Posted by Isabel Drost-Fromm <is...@apache.org>.
Hi,
Am 16. Januar 2018 01:40:48 MEZ schrieb Steffen Rochel <st...@gmail.com>:
># Anybody can add themselves or a team as additional contributors
># to get notified about changes in a specific package.
># See https://help.github.com/articles/about-teams how to setup teams.
>
>Hope we can adopt this approach.
Once you run with that approach: As to my knowledge you are the first project at Apache using the code owners function, it would be great if you could track its usage and impact on your community in coming incubator/ board reports.
When first mentioning it, make sure though to either point ppl to this thread or explain its intended use to avoid running into a second wave of warnings about things discussed here already.
Isabel
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
+1
On Mon, Jan 15, 2018 at 4:40 PM, Steffen Rochel <st...@gmail.com>
wrote:
> Thanks for all the feedback!
> Proposed a simplified version in
> https://github.com/apache/incubator-mxnet/pull/9448 :
>
> # Owners of Apache MXNet
> # Please see documentation of use of CODEOWNERS file at
> # https://help.github.com/articles/about-codeowners/ and
> # https://github.com/blog/2392-introducing-code-owners
> #
> # Anybody can add themselves or a team as additional contributors
> # to get notified about changes in a specific package.
> # See https://help.github.com/articles/about-teams how to setup teams.
> # Global owners
> ...
>
> Hope we can adopt this approach.
>
> Regards, Steffen
>
>
> On Mon, Jan 15, 2018 at 1:26 PM Marco de Abreu <
> marco.g.abreu@googlemail.com>
> wrote:
>
> > Very good points, Chris! +1
> >
> > If the community does not want to support a specific part of MXNet but
> > there's a business interest, the company can assign somebody for this
> task
> > and if this person is doing good work, they might be added as a committer
> > in the long-term, closing the loop. If there's no business- neither
> > user-interest in that part and nobody else in the community wants to take
> > care of it, it might as well get removed.
> >
> > -Marco
> >
> > On Mon, Jan 15, 2018 at 9:50 PM, Chris Olivier <cj...@gmail.com>
> > wrote:
> >
> > > I'm not sure I understand the "orphaned package" thing. You mean that
> no
> > > one is reviewing them?
> > > If a corporation wishes to assign a particular portion of the code to
> an
> > > employee to review regularly, then that can take care of any portions
> > > becoming "orphaned", but it can't mean "this person we assigned is now
> > the
> > > last word.
> > >
> > > If someone takes an interest in reviewing a particular part of the
> code,
> > > then they'd tend to add themself to the "watch list" (this CODEOWNERS
> > > file), but I don't believe that this file should dictate how important
> > one
> > > committer's reviews are compared to another. You don't entice people
> to
> > > review by telling them that their opinion is only worth half of person
> > > X's. Why would they even bother? Committers are made committers
> because
> > > they are trusted to behave competently and not merge stuff they aren't
> > > comfortable with.
> > >
> > > People work hard to become committers, but then saying that "ok you're
> a
> > > committer but really only these 5 people get to merge code unless you
> > jump
> > > through all of these hoops" isn't fair, IMHO, and won't help to build
> the
> > > community.
> > >
> > > In addition, so far the mentors seem to have discouraged this sort of
> > > "ownership" role.
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Jan 14, 2018 at 8:39 PM, Steffen Rochel <
> steffenrochel@gmail.com
> > >
> > > wrote:
> > >
> > > > Sandeep -
> > > > 1. Yes, but not only. Using maintainers the community will also know
> > who
> > > is
> > > > expert or point of contact for a specific package within the MXNet
> > repo.
> > > > 2. I suggested: By default the package maintainer should merge PR
> after
> > > > appropriate review. A PR which received 2 +1 (or LGTM) comments can
> be
> > > > merged by any committer.
> > > > Of course, open to suggestion and I assume we all know when to apply
> > > common
> > > > sense for small changes.
> > > > As we are gaining more experience with a larger community we can
> decide
> > > if
> > > > it make sense to use required reviews by the CODEOWNERS (could be one
> > or
> > > > more per package), but I think this would be to restrictive at this
> > time.
> > > >
> > > > I liked the description from github
> > > > <https://opensource.guide/leadership-and-governance/> about the role
> > of
> > > a
> > > > maintainer: "... Regardless of what they do day-to-day, a maintainer
> is
> > > > probably someone who feels responsibility over the direction of the
> > > project
> > > > and is committed to improving it. " I feel this does apply to the
> > various
> > > > packages/directories in MXNet to grow the community and project.
> > > >
> > > > Chris - can you please elaborate your concerns and suggest
> alternative?
> > > How
> > > > can we ensure certain packages will not become orphans? I do see a
> > > > maintainer as somebody with detailed knowledge who cares about an
> area
> > > and
> > > > certainly not as dictator or king.
> > > >
> > > > Steffen
> > > >
> > > > On Sun, Jan 14, 2018 at 8:00 PM sandeep krishnamurthy <
> > > > sandeep.krishna98@gmail.com> wrote:
> > > >
> > > > > Just wanted to clarify my understanding.
> > > > > 1. We are going to use Github CODEOWNERS functionality as a feature
> > for
> > > > > getting notified.
> > > > > 2. This does not mean only CODEOWNERS approved code will be merged
> > for
> > > > > respective module. (We need to evolve community to self-sustain
> > without
> > > > > getting blocked on one poc)
> > > > >
> > > > > Regards,
> > > > > Sandeep
> > > > >
> > > > > On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
> > > > > sandeep.krishna98@gmail.com> wrote:
> > > > >
> > > > > > +1 (binding) for suggestion around framing CODEOWNERS
> functionality
> > > as
> > > > > the
> > > > > > watchlist.
> > > > > > I also feel that we should enable and find/request more than 1
> > person
> > > > per
> > > > > > module to help the project.
> > > > > >
> > > > > > But, still, if it is something like +1 or watch button for
> modules
> > > > rather
> > > > > > than a new PR to follow a topic, it would have been great.
> > Something
> > > > for
> > > > > > future :-)
> > > > > >
> > > > > > Regards,
> > > > > > Sandeep
> > > > > >
> > > > > > On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <
> > > > steffenrochel@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Thanks Chris for the great reading suggestion
> > > > > >> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
> > > > > >>
> > > > > >> I'm suggesting that we adopt Mu's proposal to use github code
> > owner
> > > > > >> mechanism to identify designated maintainer for each package.
> > > > > >> To address the concerns raised in this thread I proposed
> > > > > >> to add into the header of the CODEOWNERS file
> > > > > >> https://github.com/apache/incubator-mxnet/pull/9426
> > > > > >> (changes below).
> > > > > >>
> > > > > >> Chris, Sebastian, Isabel - please suggest changes, but I hope I
> > > > > addressed
> > > > > >> your concerns.
> > > > > >>
> > > > > >> In the future we can also enable required reviews (see
> > > > > >> https://help.github.com/articles/about-pull-request-reviews/),
> > but
> > > I
> > > > > >> would
> > > > > >> suggest to make one change at a time.
> > > > > >>
> > > > > >> I do suggest we should explore how we can best adopt existing
> > github
> > > > > >> features before considering building additional CI tasks.
> > > > > >>
> > > > > >> Steffen
> > > > > >>
> > > > > >> # Please see documentation of use of CODEOWNERS file at
> > > > > >> # https://help.github.com/articles/about-codeowners/ and
> > > > > >> # https://github.com/blog/2392-introducing-code-owners
> > > > > >> #
> > > > > >> # The first owner listed for a package is considered the
> > maintainer
> > > > for
> > > > > a
> > > > > >> package.
> > > > > >> # Anybody can add themselves or a team (see
> > > > > >> https://help.github.com/articles/about-teams/)
> > > > > >> # as additional owners to get notified about changes in a
> specific
> > > > > >> package.
> > > > > >> #
> > > > > >> # By default the package maintainer should merge PR after
> > > appropriate
> > > > > >> review.
> > > > > >> # A PR which received 2 +1 (or LGTM) comments can be merged by
> any
> > > > > >> committer.
> > > > > >> # In the future we might consider adopting required reviews
> > > > > >> # (see
> > https://help.github.com/articles/about-pull-request-reviews/
> > > )
> > > > > >>
> > > > > >>
> > > > > >> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <
> > > bhavinthaker@gmail.com
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > During the MXNet 1.0 release, there was feedback from the
> > mentors
> > > > and
> > > > > >> folks
> > > > > >> > in general@ to clarify at the top of the CODEOWNERs file on
> > what
> > > > the
> > > > > >> > contents of this file meant.
> > > > > >> >
> > > > > >> > Hi Mu,
> > > > > >> >
> > > > > >> > Please add the description of the file in the file header. I
> > > expect
> > > > > that
> > > > > >> > this will be a requirement for the next MXNet release 1.0.1.
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Bhavin Thaker.
> > > > > >> >
> > > > > >> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <
> > > > cjolivier01@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > i’d be +1 if CODEOWNERS file has a big note at the top
> saying
> > > > > >> basically
> > > > > >> > > it’s just for watching code changes that you’d like to know
> > > about
> > > > > (to
> > > > > >> > > review or just to follow) and that anyone can add themself.
> > > > > >> > >
> > > > > >> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <
> > > > > cjolivier01@gmail.com>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > > Does it have to be called "CODEOWNERS"? I would be more
> > > > > comfortable
> > > > > >> > with
> > > > > >> > > > it if it's a "watch list" where it just means you wish to
> > > watch
> > > > > code
> > > > > >> > here
> > > > > >> > > > or there in the source structure and anyone can add or
> > remove
> > > > > their
> > > > > >> > name
> > > > > >> > > > from watching some part of the code at any time.
> > > > > >> > > >
> > > > > >> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > > > > >> > > > marco.g.abreu@googlemail.com> wrote:
> > > > > >> > > >
> > > > > >> > > >> I agree. How about we find another way to allow people to
> > > > > subscribe
> > > > > >> > for
> > > > > >> > > >> changes in a specific file or directory?
> > > > > >> > > >>
> > > > > >> > > >> -Marco
> > > > > >> > > >>
> > > > > >> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > > > > >> > > cjolivier01@gmail.com
> > > > > >> > > >> >:
> > > > > >> > > >>
> > > > > >> > > >> > Have you read "The Cathedral and the Bazaar"?
> > > > > >> > > >> >
> > > > > >> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > > > > >> > > >> >
> > > > > >> > > >> > One of the points I took from this is that once a
> project
> > > > finds
> > > > > >> its
> > > > > >> > > >> stride,
> > > > > >> > > >> > it actually runs more efficiently without
> centralization
> > > than
> > > > > >> with.
> > > > > >> > > >> >
> > > > > >> > > >> > -Chris
> > > > > >> > > >> >
> > > > > >> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > > > > >> > > >> > marco.g.abreu@googlemail.com> wrote:
> > > > > >> > > >> >
> > > > > >> > > >> > > Hi Chris,
> > > > > >> > > >> > >
> > > > > >> > > >> > > you have a good point about people being afraid of
> > > > reviewing
> > > > > >> PRs
> > > > > >> > > which
> > > > > >> > > >> > they
> > > > > >> > > >> > > are not assigned to and I totally agree that we
> should
> > > > > >> encourage
> > > > > >> > > >> > everybody
> > > > > >> > > >> > > to review PRs.
> > > > > >> > > >> > >
> > > > > >> > > >> > > One important advantage I see in this is the
> > > notification:
> > > > > >> since
> > > > > >> > we
> > > > > >> > > >> are
> > > > > >> > > >> > not
> > > > > >> > > >> > > using the feature to required an approval, this step
> is
> > > > > >> entirely
> > > > > >> > for
> > > > > >> > > >> > > information purpose. I, for example, would like to
> get
> > > > > notified
> > > > > >> > if a
> > > > > >> > > >> PR
> > > > > >> > > >> > to
> > > > > >> > > >> > > change a CI file would be created. Just as an
> example:
> > > over
> > > > > >> > > >> Christmas, a
> > > > > >> > > >> > PR
> > > > > >> > > >> > > to update mkl has been pushed without me knowing
> about
> > > it.
> > > > > >> > Somehow,
> > > > > >> > > >> after
> > > > > >> > > >> > > my vacation, we started to get issues with mkl test
> - I
> > > > only
> > > > > >> found
> > > > > >> > > out
> > > > > >> > > >> > > about this PR after quite a long investigation. If we
> > > would
> > > > > >> extend
> > > > > >> > > the
> > > > > >> > > >> > > usage of the code maintainers, we'll make sure that
> > > changes
> > > > > >> like
> > > > > >> > > these
> > > > > >> > > >> > will
> > > > > >> > > >> > > notify the people who have the best knowledge about
> > that
> > > > > part.
> > > > > >> > > >> > >
> > > > > >> > > >> > > Marco
> > > > > >> > > >> > >
> > > > > >> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > > > > >> > > >> cjolivier01@gmail.com
> > > > > >> > > >> > >:
> > > > > >> > > >> > >
> > > > > >> > > >> > > > -1 (binding)
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > I totally understand the motivation for this (I've
> > > > > definitely
> > > > > >> > > saved
> > > > > >> > > >> > > myself
> > > > > >> > > >> > > > some grief by getting called out automatically for
> > > > > >> > CMakeLists.txt
> > > > > >> > > >> > stuff,
> > > > > >> > > >> > > > for example), but I respectfully decline for the
> > > > following
> > > > > >> > > >> reason(s):
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > I feel that defining code-owners has some negative
> > > > effects.
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > Other committers may be reluctant to start
> reviewing
> > > and
> > > > > >> > approving
> > > > > >> > > >> PRs
> > > > > >> > > >> > > > since they aren't the one listed, so I feel this
> will
> > > in
> > > > > the
> > > > > >> > > >> long-run
> > > > > >> > > >> > > > reduce the number of people doing code reviews.
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > If there aren't enough people doing PR's, then
> people
> > > can
> > > > > >> > complain
> > > > > >> > > >> on
> > > > > >> > > >> > > dev@
> > > > > >> > > >> > > > asking for review.
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > -Chris
> > > > > >> > > >> > > >
> > > > > >> > > >> > > >
> > > > > >> > > >> > > >
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> > > > > >> haibin@apache.org
> > > > > >> > >
> > > > > >> > > >> > wrote:
> > > > > >> > > >> > > >
> > > > > >> > > >> > > > > +1 (binding)
> > > > > >> > > >> > > > >
> > > > > >> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > > > > >> > > >> kellen.sunderland@gmail.com>
> > > > > >> > > >> > > > > wrote:
> > > > > >> > > >> > > > > > +1 (non-binding)
> > > > > >> > > >> > > > > >
> > > > > >> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > > > > >> > > >> steffenrochel@gmail.com
> > > > > >> > > >> > >
> > > > > >> > > >> > > > > wrote:
> > > > > >> > > >> > > > > >
> > > > > >> > > >> > > > > > > I propose to adopt the proposal.
> > > > > >> > > >> > > > > > > +1 (non-binding)
> > > > > >> > > >> > > > > > >
> > > > > >> > > >> > > > > > > Steffen
> > > > > >> > > >> > > > > > >
> > > > > >> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> > > > > >> muli.cmu@gmail.com
> > > > > >> > >
> > > > > >> > > >> > wrote:
> > > > > >> > > >> > > > > > >
> > > > > >> > > >> > > > > > > > Hi Isabel,
> > > > > >> > > >> > > > > > > >
> > > > > >> > > >> > > > > > > > My apologies that not saying that clearly.
> > > > > >> > > >> > > > > > > >
> > > > > >> > > >> > > > > > > > The purpose of this proposal is encouraging
> > > more
> > > > > >> > > >> contributors
> > > > > >> > > >> > to
> > > > > >> > > >> > > > help
> > > > > >> > > >> > > > > > > > review and merge PRs. And also hope to
> > shorten
> > > > the
> > > > > >> time
> > > > > >> > > for
> > > > > >> > > >> a
> > > > > >> > > >> > PR
> > > > > >> > > >> > > to
> > > > > >> > > >> > > > > be
> > > > > >> > > >> > > > > > > > merged. After assigning maintainers to
> > modules,
> > > > > then
> > > > > >> PR
> > > > > >> > > >> > > > contributors
> > > > > >> > > >> > > > > can
> > > > > >> > > >> > > > > > > > easily contact the reviewers. In other
> words,
> > > > > github
> > > > > >> > will
> > > > > >> > > >> > > > > automatically
> > > > > >> > > >> > > > > > > > assign the PR to the maintainer and send a
> > > > > >> notification
> > > > > >> > > >> email.
> > > > > >> > > >> > > > > > > >
> > > > > >> > > >> > > > > > > > I don't think I put the term "inbox" in my
> > > > > proposal.
> > > > > >> I
> > > > > >> > > never
> > > > > >> > > >> > > > > discussed
> > > > > >> > > >> > > > > > > PRs
> > > > > >> > > >> > > > > > > > with other contributors by sending email
> > > > directly,
> > > > > >> which
> > > > > >> > > is
> > > > > >> > > >> > less
> > > > > >> > > >> > > > > > > effective
> > > > > >> > > >> > > > > > > > than just using github. I also don't aware
> > any
> > > > > other
> > > > > >> > > >> > contributor
> > > > > >> > > >> > > > use
> > > > > >> > > >> > > > > the
> > > > > >> > > >> > > > > > > > direct email way. So I didn't clarify it on
> > the
> > > > > >> > proposal.
> > > > > >> > > >> > > > > > > >
> > > > > >> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel
> > > > > Drost-Fromm <
> > > > > >> > > >> > > > > isabel@apache.org>
> > > > > >> > > >> > > > > > > > wrote:
> > > > > >> > > >> > > > > > > >
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu
> > Li
> > > <
> > > > > >> > > >> > > muli.cmu@gmail.com
> > > > > >> > > >> > > > >:
> > > > > >> > > >> > > > > > > > > >We should encourage to contract a
> specific
> > > > > >> > contributor
> > > > > >> > > >> for
> > > > > >> > > >> > > > issues
> > > > > >> > > >> > > > > and
> > > > > >> > > >> > > > > > > > > >PRs.
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > > My head translates "encourage to contact
> > > > specific
> > > > > >> > > >> > contributor"
> > > > > >> > > >> > > > into
> > > > > >> > > >> > > > > > > > > "encourage to contact specific
> contributors
> > > > > inbox".
> > > > > >> > This
> > > > > >> > > >> > > > translated
> > > > > >> > > >> > > > > > > > version
> > > > > >> > > >> > > > > > > > > is what I would highly discourage.
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > > See the disclaimer here for reasons
> behind
> > > > that:
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > >
> > https://home.apache.org/~hossman/#private_q
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > > > Isabel
> > > > > >> > > >> > > > > > > > > --
> > > > > >> > > >> > > > > > > > > Diese Nachricht wurde von meinem
> > > Android-Gerät
> > > > > mit
> > > > > >> K-9
> > > > > >> > > >> Mail
> > > > > >> > > >> > > > > gesendet.
> > > > > >> > > >> > > > > > > > >
> > > > > >> > > >> > > > > > > >
> > > > > >> > > >> > > > > > >
> > > > > >> > > >> > > > > >
> > > > > >> > > >> > > > >
> > > > > >> > > >> > > >
> > > > > >> > > >> > >
> > > > > >> > > >> >
> > > > > >> > > >>
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sandeep Krishnamurthy
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sandeep Krishnamurthy
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Steffen Rochel <st...@gmail.com>.
Thanks for all the feedback!
Proposed a simplified version in
https://github.com/apache/incubator-mxnet/pull/9448 :
# Owners of Apache MXNet
# Please see documentation of use of CODEOWNERS file at
# https://help.github.com/articles/about-codeowners/ and
# https://github.com/blog/2392-introducing-code-owners
#
# Anybody can add themselves or a team as additional contributors
# to get notified about changes in a specific package.
# See https://help.github.com/articles/about-teams how to setup teams.
# Global owners
...
Hope we can adopt this approach.
Regards, Steffen
On Mon, Jan 15, 2018 at 1:26 PM Marco de Abreu <ma...@googlemail.com>
wrote:
> Very good points, Chris! +1
>
> If the community does not want to support a specific part of MXNet but
> there's a business interest, the company can assign somebody for this task
> and if this person is doing good work, they might be added as a committer
> in the long-term, closing the loop. If there's no business- neither
> user-interest in that part and nobody else in the community wants to take
> care of it, it might as well get removed.
>
> -Marco
>
> On Mon, Jan 15, 2018 at 9:50 PM, Chris Olivier <cj...@gmail.com>
> wrote:
>
> > I'm not sure I understand the "orphaned package" thing. You mean that no
> > one is reviewing them?
> > If a corporation wishes to assign a particular portion of the code to an
> > employee to review regularly, then that can take care of any portions
> > becoming "orphaned", but it can't mean "this person we assigned is now
> the
> > last word.
> >
> > If someone takes an interest in reviewing a particular part of the code,
> > then they'd tend to add themself to the "watch list" (this CODEOWNERS
> > file), but I don't believe that this file should dictate how important
> one
> > committer's reviews are compared to another. You don't entice people to
> > review by telling them that their opinion is only worth half of person
> > X's. Why would they even bother? Committers are made committers because
> > they are trusted to behave competently and not merge stuff they aren't
> > comfortable with.
> >
> > People work hard to become committers, but then saying that "ok you're a
> > committer but really only these 5 people get to merge code unless you
> jump
> > through all of these hoops" isn't fair, IMHO, and won't help to build the
> > community.
> >
> > In addition, so far the mentors seem to have discouraged this sort of
> > "ownership" role.
> >
> >
> >
> >
> >
> > On Sun, Jan 14, 2018 at 8:39 PM, Steffen Rochel <steffenrochel@gmail.com
> >
> > wrote:
> >
> > > Sandeep -
> > > 1. Yes, but not only. Using maintainers the community will also know
> who
> > is
> > > expert or point of contact for a specific package within the MXNet
> repo.
> > > 2. I suggested: By default the package maintainer should merge PR after
> > > appropriate review. A PR which received 2 +1 (or LGTM) comments can be
> > > merged by any committer.
> > > Of course, open to suggestion and I assume we all know when to apply
> > common
> > > sense for small changes.
> > > As we are gaining more experience with a larger community we can decide
> > if
> > > it make sense to use required reviews by the CODEOWNERS (could be one
> or
> > > more per package), but I think this would be to restrictive at this
> time.
> > >
> > > I liked the description from github
> > > <https://opensource.guide/leadership-and-governance/> about the role
> of
> > a
> > > maintainer: "... Regardless of what they do day-to-day, a maintainer is
> > > probably someone who feels responsibility over the direction of the
> > project
> > > and is committed to improving it. " I feel this does apply to the
> various
> > > packages/directories in MXNet to grow the community and project.
> > >
> > > Chris - can you please elaborate your concerns and suggest alternative?
> > How
> > > can we ensure certain packages will not become orphans? I do see a
> > > maintainer as somebody with detailed knowledge who cares about an area
> > and
> > > certainly not as dictator or king.
> > >
> > > Steffen
> > >
> > > On Sun, Jan 14, 2018 at 8:00 PM sandeep krishnamurthy <
> > > sandeep.krishna98@gmail.com> wrote:
> > >
> > > > Just wanted to clarify my understanding.
> > > > 1. We are going to use Github CODEOWNERS functionality as a feature
> for
> > > > getting notified.
> > > > 2. This does not mean only CODEOWNERS approved code will be merged
> for
> > > > respective module. (We need to evolve community to self-sustain
> without
> > > > getting blocked on one poc)
> > > >
> > > > Regards,
> > > > Sandeep
> > > >
> > > > On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
> > > > sandeep.krishna98@gmail.com> wrote:
> > > >
> > > > > +1 (binding) for suggestion around framing CODEOWNERS functionality
> > as
> > > > the
> > > > > watchlist.
> > > > > I also feel that we should enable and find/request more than 1
> person
> > > per
> > > > > module to help the project.
> > > > >
> > > > > But, still, if it is something like +1 or watch button for modules
> > > rather
> > > > > than a new PR to follow a topic, it would have been great.
> Something
> > > for
> > > > > future :-)
> > > > >
> > > > > Regards,
> > > > > Sandeep
> > > > >
> > > > > On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <
> > > steffenrochel@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Thanks Chris for the great reading suggestion
> > > > >> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
> > > > >>
> > > > >> I'm suggesting that we adopt Mu's proposal to use github code
> owner
> > > > >> mechanism to identify designated maintainer for each package.
> > > > >> To address the concerns raised in this thread I proposed
> > > > >> to add into the header of the CODEOWNERS file
> > > > >> https://github.com/apache/incubator-mxnet/pull/9426
> > > > >> (changes below).
> > > > >>
> > > > >> Chris, Sebastian, Isabel - please suggest changes, but I hope I
> > > > addressed
> > > > >> your concerns.
> > > > >>
> > > > >> In the future we can also enable required reviews (see
> > > > >> https://help.github.com/articles/about-pull-request-reviews/),
> but
> > I
> > > > >> would
> > > > >> suggest to make one change at a time.
> > > > >>
> > > > >> I do suggest we should explore how we can best adopt existing
> github
> > > > >> features before considering building additional CI tasks.
> > > > >>
> > > > >> Steffen
> > > > >>
> > > > >> # Please see documentation of use of CODEOWNERS file at
> > > > >> # https://help.github.com/articles/about-codeowners/ and
> > > > >> # https://github.com/blog/2392-introducing-code-owners
> > > > >> #
> > > > >> # The first owner listed for a package is considered the
> maintainer
> > > for
> > > > a
> > > > >> package.
> > > > >> # Anybody can add themselves or a team (see
> > > > >> https://help.github.com/articles/about-teams/)
> > > > >> # as additional owners to get notified about changes in a specific
> > > > >> package.
> > > > >> #
> > > > >> # By default the package maintainer should merge PR after
> > appropriate
> > > > >> review.
> > > > >> # A PR which received 2 +1 (or LGTM) comments can be merged by any
> > > > >> committer.
> > > > >> # In the future we might consider adopting required reviews
> > > > >> # (see
> https://help.github.com/articles/about-pull-request-reviews/
> > )
> > > > >>
> > > > >>
> > > > >> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <
> > bhavinthaker@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >> > During the MXNet 1.0 release, there was feedback from the
> mentors
> > > and
> > > > >> folks
> > > > >> > in general@ to clarify at the top of the CODEOWNERs file on
> what
> > > the
> > > > >> > contents of this file meant.
> > > > >> >
> > > > >> > Hi Mu,
> > > > >> >
> > > > >> > Please add the description of the file in the file header. I
> > expect
> > > > that
> > > > >> > this will be a requirement for the next MXNet release 1.0.1.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Bhavin Thaker.
> > > > >> >
> > > > >> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <
> > > cjolivier01@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > i’d be +1 if CODEOWNERS file has a big note at the top saying
> > > > >> basically
> > > > >> > > it’s just for watching code changes that you’d like to know
> > about
> > > > (to
> > > > >> > > review or just to follow) and that anyone can add themself.
> > > > >> > >
> > > > >> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <
> > > > cjolivier01@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Does it have to be called "CODEOWNERS"? I would be more
> > > > comfortable
> > > > >> > with
> > > > >> > > > it if it's a "watch list" where it just means you wish to
> > watch
> > > > code
> > > > >> > here
> > > > >> > > > or there in the source structure and anyone can add or
> remove
> > > > their
> > > > >> > name
> > > > >> > > > from watching some part of the code at any time.
> > > > >> > > >
> > > > >> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > > > >> > > > marco.g.abreu@googlemail.com> wrote:
> > > > >> > > >
> > > > >> > > >> I agree. How about we find another way to allow people to
> > > > subscribe
> > > > >> > for
> > > > >> > > >> changes in a specific file or directory?
> > > > >> > > >>
> > > > >> > > >> -Marco
> > > > >> > > >>
> > > > >> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > > > >> > > cjolivier01@gmail.com
> > > > >> > > >> >:
> > > > >> > > >>
> > > > >> > > >> > Have you read "The Cathedral and the Bazaar"?
> > > > >> > > >> >
> > > > >> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > > > >> > > >> >
> > > > >> > > >> > One of the points I took from this is that once a project
> > > finds
> > > > >> its
> > > > >> > > >> stride,
> > > > >> > > >> > it actually runs more efficiently without centralization
> > than
> > > > >> with.
> > > > >> > > >> >
> > > > >> > > >> > -Chris
> > > > >> > > >> >
> > > > >> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > > > >> > > >> > marco.g.abreu@googlemail.com> wrote:
> > > > >> > > >> >
> > > > >> > > >> > > Hi Chris,
> > > > >> > > >> > >
> > > > >> > > >> > > you have a good point about people being afraid of
> > > reviewing
> > > > >> PRs
> > > > >> > > which
> > > > >> > > >> > they
> > > > >> > > >> > > are not assigned to and I totally agree that we should
> > > > >> encourage
> > > > >> > > >> > everybody
> > > > >> > > >> > > to review PRs.
> > > > >> > > >> > >
> > > > >> > > >> > > One important advantage I see in this is the
> > notification:
> > > > >> since
> > > > >> > we
> > > > >> > > >> are
> > > > >> > > >> > not
> > > > >> > > >> > > using the feature to required an approval, this step is
> > > > >> entirely
> > > > >> > for
> > > > >> > > >> > > information purpose. I, for example, would like to get
> > > > notified
> > > > >> > if a
> > > > >> > > >> PR
> > > > >> > > >> > to
> > > > >> > > >> > > change a CI file would be created. Just as an example:
> > over
> > > > >> > > >> Christmas, a
> > > > >> > > >> > PR
> > > > >> > > >> > > to update mkl has been pushed without me knowing about
> > it.
> > > > >> > Somehow,
> > > > >> > > >> after
> > > > >> > > >> > > my vacation, we started to get issues with mkl test - I
> > > only
> > > > >> found
> > > > >> > > out
> > > > >> > > >> > > about this PR after quite a long investigation. If we
> > would
> > > > >> extend
> > > > >> > > the
> > > > >> > > >> > > usage of the code maintainers, we'll make sure that
> > changes
> > > > >> like
> > > > >> > > these
> > > > >> > > >> > will
> > > > >> > > >> > > notify the people who have the best knowledge about
> that
> > > > part.
> > > > >> > > >> > >
> > > > >> > > >> > > Marco
> > > > >> > > >> > >
> > > > >> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > > > >> > > >> cjolivier01@gmail.com
> > > > >> > > >> > >:
> > > > >> > > >> > >
> > > > >> > > >> > > > -1 (binding)
> > > > >> > > >> > > >
> > > > >> > > >> > > > I totally understand the motivation for this (I've
> > > > definitely
> > > > >> > > saved
> > > > >> > > >> > > myself
> > > > >> > > >> > > > some grief by getting called out automatically for
> > > > >> > CMakeLists.txt
> > > > >> > > >> > stuff,
> > > > >> > > >> > > > for example), but I respectfully decline for the
> > > following
> > > > >> > > >> reason(s):
> > > > >> > > >> > > >
> > > > >> > > >> > > > I feel that defining code-owners has some negative
> > > effects.
> > > > >> > > >> > > >
> > > > >> > > >> > > > Other committers may be reluctant to start reviewing
> > and
> > > > >> > approving
> > > > >> > > >> PRs
> > > > >> > > >> > > > since they aren't the one listed, so I feel this will
> > in
> > > > the
> > > > >> > > >> long-run
> > > > >> > > >> > > > reduce the number of people doing code reviews.
> > > > >> > > >> > > >
> > > > >> > > >> > > > If there aren't enough people doing PR's, then people
> > can
> > > > >> > complain
> > > > >> > > >> on
> > > > >> > > >> > > dev@
> > > > >> > > >> > > > asking for review.
> > > > >> > > >> > > >
> > > > >> > > >> > > > -Chris
> > > > >> > > >> > > >
> > > > >> > > >> > > >
> > > > >> > > >> > > >
> > > > >> > > >> > > >
> > > > >> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> > > > >> haibin@apache.org
> > > > >> > >
> > > > >> > > >> > wrote:
> > > > >> > > >> > > >
> > > > >> > > >> > > > > +1 (binding)
> > > > >> > > >> > > > >
> > > > >> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > > > >> > > >> kellen.sunderland@gmail.com>
> > > > >> > > >> > > > > wrote:
> > > > >> > > >> > > > > > +1 (non-binding)
> > > > >> > > >> > > > > >
> > > > >> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > > > >> > > >> steffenrochel@gmail.com
> > > > >> > > >> > >
> > > > >> > > >> > > > > wrote:
> > > > >> > > >> > > > > >
> > > > >> > > >> > > > > > > I propose to adopt the proposal.
> > > > >> > > >> > > > > > > +1 (non-binding)
> > > > >> > > >> > > > > > >
> > > > >> > > >> > > > > > > Steffen
> > > > >> > > >> > > > > > >
> > > > >> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> > > > >> muli.cmu@gmail.com
> > > > >> > >
> > > > >> > > >> > wrote:
> > > > >> > > >> > > > > > >
> > > > >> > > >> > > > > > > > Hi Isabel,
> > > > >> > > >> > > > > > > >
> > > > >> > > >> > > > > > > > My apologies that not saying that clearly.
> > > > >> > > >> > > > > > > >
> > > > >> > > >> > > > > > > > The purpose of this proposal is encouraging
> > more
> > > > >> > > >> contributors
> > > > >> > > >> > to
> > > > >> > > >> > > > help
> > > > >> > > >> > > > > > > > review and merge PRs. And also hope to
> shorten
> > > the
> > > > >> time
> > > > >> > > for
> > > > >> > > >> a
> > > > >> > > >> > PR
> > > > >> > > >> > > to
> > > > >> > > >> > > > > be
> > > > >> > > >> > > > > > > > merged. After assigning maintainers to
> modules,
> > > > then
> > > > >> PR
> > > > >> > > >> > > > contributors
> > > > >> > > >> > > > > can
> > > > >> > > >> > > > > > > > easily contact the reviewers. In other words,
> > > > github
> > > > >> > will
> > > > >> > > >> > > > > automatically
> > > > >> > > >> > > > > > > > assign the PR to the maintainer and send a
> > > > >> notification
> > > > >> > > >> email.
> > > > >> > > >> > > > > > > >
> > > > >> > > >> > > > > > > > I don't think I put the term "inbox" in my
> > > > proposal.
> > > > >> I
> > > > >> > > never
> > > > >> > > >> > > > > discussed
> > > > >> > > >> > > > > > > PRs
> > > > >> > > >> > > > > > > > with other contributors by sending email
> > > directly,
> > > > >> which
> > > > >> > > is
> > > > >> > > >> > less
> > > > >> > > >> > > > > > > effective
> > > > >> > > >> > > > > > > > than just using github. I also don't aware
> any
> > > > other
> > > > >> > > >> > contributor
> > > > >> > > >> > > > use
> > > > >> > > >> > > > > the
> > > > >> > > >> > > > > > > > direct email way. So I didn't clarify it on
> the
> > > > >> > proposal.
> > > > >> > > >> > > > > > > >
> > > > >> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel
> > > > Drost-Fromm <
> > > > >> > > >> > > > > isabel@apache.org>
> > > > >> > > >> > > > > > > > wrote:
> > > > >> > > >> > > > > > > >
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu
> Li
> > <
> > > > >> > > >> > > muli.cmu@gmail.com
> > > > >> > > >> > > > >:
> > > > >> > > >> > > > > > > > > >We should encourage to contract a specific
> > > > >> > contributor
> > > > >> > > >> for
> > > > >> > > >> > > > issues
> > > > >> > > >> > > > > and
> > > > >> > > >> > > > > > > > > >PRs.
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > > My head translates "encourage to contact
> > > specific
> > > > >> > > >> > contributor"
> > > > >> > > >> > > > into
> > > > >> > > >> > > > > > > > > "encourage to contact specific contributors
> > > > inbox".
> > > > >> > This
> > > > >> > > >> > > > translated
> > > > >> > > >> > > > > > > > version
> > > > >> > > >> > > > > > > > > is what I would highly discourage.
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > > See the disclaimer here for reasons behind
> > > that:
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > >
> https://home.apache.org/~hossman/#private_q
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > > > Isabel
> > > > >> > > >> > > > > > > > > --
> > > > >> > > >> > > > > > > > > Diese Nachricht wurde von meinem
> > Android-Gerät
> > > > mit
> > > > >> K-9
> > > > >> > > >> Mail
> > > > >> > > >> > > > > gesendet.
> > > > >> > > >> > > > > > > > >
> > > > >> > > >> > > > > > > >
> > > > >> > > >> > > > > > >
> > > > >> > > >> > > > > >
> > > > >> > > >> > > > >
> > > > >> > > >> > > >
> > > > >> > > >> > >
> > > > >> > > >> >
> > > > >> > > >>
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sandeep Krishnamurthy
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sandeep Krishnamurthy
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Marco de Abreu <ma...@googlemail.com>.
Very good points, Chris! +1
If the community does not want to support a specific part of MXNet but
there's a business interest, the company can assign somebody for this task
and if this person is doing good work, they might be added as a committer
in the long-term, closing the loop. If there's no business- neither
user-interest in that part and nobody else in the community wants to take
care of it, it might as well get removed.
-Marco
On Mon, Jan 15, 2018 at 9:50 PM, Chris Olivier <cj...@gmail.com>
wrote:
> I'm not sure I understand the "orphaned package" thing. You mean that no
> one is reviewing them?
> If a corporation wishes to assign a particular portion of the code to an
> employee to review regularly, then that can take care of any portions
> becoming "orphaned", but it can't mean "this person we assigned is now the
> last word.
>
> If someone takes an interest in reviewing a particular part of the code,
> then they'd tend to add themself to the "watch list" (this CODEOWNERS
> file), but I don't believe that this file should dictate how important one
> committer's reviews are compared to another. You don't entice people to
> review by telling them that their opinion is only worth half of person
> X's. Why would they even bother? Committers are made committers because
> they are trusted to behave competently and not merge stuff they aren't
> comfortable with.
>
> People work hard to become committers, but then saying that "ok you're a
> committer but really only these 5 people get to merge code unless you jump
> through all of these hoops" isn't fair, IMHO, and won't help to build the
> community.
>
> In addition, so far the mentors seem to have discouraged this sort of
> "ownership" role.
>
>
>
>
>
> On Sun, Jan 14, 2018 at 8:39 PM, Steffen Rochel <st...@gmail.com>
> wrote:
>
> > Sandeep -
> > 1. Yes, but not only. Using maintainers the community will also know who
> is
> > expert or point of contact for a specific package within the MXNet repo.
> > 2. I suggested: By default the package maintainer should merge PR after
> > appropriate review. A PR which received 2 +1 (or LGTM) comments can be
> > merged by any committer.
> > Of course, open to suggestion and I assume we all know when to apply
> common
> > sense for small changes.
> > As we are gaining more experience with a larger community we can decide
> if
> > it make sense to use required reviews by the CODEOWNERS (could be one or
> > more per package), but I think this would be to restrictive at this time.
> >
> > I liked the description from github
> > <https://opensource.guide/leadership-and-governance/> about the role of
> a
> > maintainer: "... Regardless of what they do day-to-day, a maintainer is
> > probably someone who feels responsibility over the direction of the
> project
> > and is committed to improving it. " I feel this does apply to the various
> > packages/directories in MXNet to grow the community and project.
> >
> > Chris - can you please elaborate your concerns and suggest alternative?
> How
> > can we ensure certain packages will not become orphans? I do see a
> > maintainer as somebody with detailed knowledge who cares about an area
> and
> > certainly not as dictator or king.
> >
> > Steffen
> >
> > On Sun, Jan 14, 2018 at 8:00 PM sandeep krishnamurthy <
> > sandeep.krishna98@gmail.com> wrote:
> >
> > > Just wanted to clarify my understanding.
> > > 1. We are going to use Github CODEOWNERS functionality as a feature for
> > > getting notified.
> > > 2. This does not mean only CODEOWNERS approved code will be merged for
> > > respective module. (We need to evolve community to self-sustain without
> > > getting blocked on one poc)
> > >
> > > Regards,
> > > Sandeep
> > >
> > > On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
> > > sandeep.krishna98@gmail.com> wrote:
> > >
> > > > +1 (binding) for suggestion around framing CODEOWNERS functionality
> as
> > > the
> > > > watchlist.
> > > > I also feel that we should enable and find/request more than 1 person
> > per
> > > > module to help the project.
> > > >
> > > > But, still, if it is something like +1 or watch button for modules
> > rather
> > > > than a new PR to follow a topic, it would have been great. Something
> > for
> > > > future :-)
> > > >
> > > > Regards,
> > > > Sandeep
> > > >
> > > > On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <
> > steffenrochel@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Thanks Chris for the great reading suggestion
> > > >> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
> > > >>
> > > >> I'm suggesting that we adopt Mu's proposal to use github code owner
> > > >> mechanism to identify designated maintainer for each package.
> > > >> To address the concerns raised in this thread I proposed
> > > >> to add into the header of the CODEOWNERS file
> > > >> https://github.com/apache/incubator-mxnet/pull/9426
> > > >> (changes below).
> > > >>
> > > >> Chris, Sebastian, Isabel - please suggest changes, but I hope I
> > > addressed
> > > >> your concerns.
> > > >>
> > > >> In the future we can also enable required reviews (see
> > > >> https://help.github.com/articles/about-pull-request-reviews/), but
> I
> > > >> would
> > > >> suggest to make one change at a time.
> > > >>
> > > >> I do suggest we should explore how we can best adopt existing github
> > > >> features before considering building additional CI tasks.
> > > >>
> > > >> Steffen
> > > >>
> > > >> # Please see documentation of use of CODEOWNERS file at
> > > >> # https://help.github.com/articles/about-codeowners/ and
> > > >> # https://github.com/blog/2392-introducing-code-owners
> > > >> #
> > > >> # The first owner listed for a package is considered the maintainer
> > for
> > > a
> > > >> package.
> > > >> # Anybody can add themselves or a team (see
> > > >> https://help.github.com/articles/about-teams/)
> > > >> # as additional owners to get notified about changes in a specific
> > > >> package.
> > > >> #
> > > >> # By default the package maintainer should merge PR after
> appropriate
> > > >> review.
> > > >> # A PR which received 2 +1 (or LGTM) comments can be merged by any
> > > >> committer.
> > > >> # In the future we might consider adopting required reviews
> > > >> # (see https://help.github.com/articles/about-pull-request-reviews/
> )
> > > >>
> > > >>
> > > >> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <
> bhavinthaker@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > During the MXNet 1.0 release, there was feedback from the mentors
> > and
> > > >> folks
> > > >> > in general@ to clarify at the top of the CODEOWNERs file on what
> > the
> > > >> > contents of this file meant.
> > > >> >
> > > >> > Hi Mu,
> > > >> >
> > > >> > Please add the description of the file in the file header. I
> expect
> > > that
> > > >> > this will be a requirement for the next MXNet release 1.0.1.
> > > >> >
> > > >> > Thanks,
> > > >> > Bhavin Thaker.
> > > >> >
> > > >> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <
> > cjolivier01@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > i’d be +1 if CODEOWNERS file has a big note at the top saying
> > > >> basically
> > > >> > > it’s just for watching code changes that you’d like to know
> about
> > > (to
> > > >> > > review or just to follow) and that anyone can add themself.
> > > >> > >
> > > >> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <
> > > cjolivier01@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Does it have to be called "CODEOWNERS"? I would be more
> > > comfortable
> > > >> > with
> > > >> > > > it if it's a "watch list" where it just means you wish to
> watch
> > > code
> > > >> > here
> > > >> > > > or there in the source structure and anyone can add or remove
> > > their
> > > >> > name
> > > >> > > > from watching some part of the code at any time.
> > > >> > > >
> > > >> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > > >> > > > marco.g.abreu@googlemail.com> wrote:
> > > >> > > >
> > > >> > > >> I agree. How about we find another way to allow people to
> > > subscribe
> > > >> > for
> > > >> > > >> changes in a specific file or directory?
> > > >> > > >>
> > > >> > > >> -Marco
> > > >> > > >>
> > > >> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > > >> > > cjolivier01@gmail.com
> > > >> > > >> >:
> > > >> > > >>
> > > >> > > >> > Have you read "The Cathedral and the Bazaar"?
> > > >> > > >> >
> > > >> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > > >> > > >> >
> > > >> > > >> > One of the points I took from this is that once a project
> > finds
> > > >> its
> > > >> > > >> stride,
> > > >> > > >> > it actually runs more efficiently without centralization
> than
> > > >> with.
> > > >> > > >> >
> > > >> > > >> > -Chris
> > > >> > > >> >
> > > >> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > > >> > > >> > marco.g.abreu@googlemail.com> wrote:
> > > >> > > >> >
> > > >> > > >> > > Hi Chris,
> > > >> > > >> > >
> > > >> > > >> > > you have a good point about people being afraid of
> > reviewing
> > > >> PRs
> > > >> > > which
> > > >> > > >> > they
> > > >> > > >> > > are not assigned to and I totally agree that we should
> > > >> encourage
> > > >> > > >> > everybody
> > > >> > > >> > > to review PRs.
> > > >> > > >> > >
> > > >> > > >> > > One important advantage I see in this is the
> notification:
> > > >> since
> > > >> > we
> > > >> > > >> are
> > > >> > > >> > not
> > > >> > > >> > > using the feature to required an approval, this step is
> > > >> entirely
> > > >> > for
> > > >> > > >> > > information purpose. I, for example, would like to get
> > > notified
> > > >> > if a
> > > >> > > >> PR
> > > >> > > >> > to
> > > >> > > >> > > change a CI file would be created. Just as an example:
> over
> > > >> > > >> Christmas, a
> > > >> > > >> > PR
> > > >> > > >> > > to update mkl has been pushed without me knowing about
> it.
> > > >> > Somehow,
> > > >> > > >> after
> > > >> > > >> > > my vacation, we started to get issues with mkl test - I
> > only
> > > >> found
> > > >> > > out
> > > >> > > >> > > about this PR after quite a long investigation. If we
> would
> > > >> extend
> > > >> > > the
> > > >> > > >> > > usage of the code maintainers, we'll make sure that
> changes
> > > >> like
> > > >> > > these
> > > >> > > >> > will
> > > >> > > >> > > notify the people who have the best knowledge about that
> > > part.
> > > >> > > >> > >
> > > >> > > >> > > Marco
> > > >> > > >> > >
> > > >> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > > >> > > >> cjolivier01@gmail.com
> > > >> > > >> > >:
> > > >> > > >> > >
> > > >> > > >> > > > -1 (binding)
> > > >> > > >> > > >
> > > >> > > >> > > > I totally understand the motivation for this (I've
> > > definitely
> > > >> > > saved
> > > >> > > >> > > myself
> > > >> > > >> > > > some grief by getting called out automatically for
> > > >> > CMakeLists.txt
> > > >> > > >> > stuff,
> > > >> > > >> > > > for example), but I respectfully decline for the
> > following
> > > >> > > >> reason(s):
> > > >> > > >> > > >
> > > >> > > >> > > > I feel that defining code-owners has some negative
> > effects.
> > > >> > > >> > > >
> > > >> > > >> > > > Other committers may be reluctant to start reviewing
> and
> > > >> > approving
> > > >> > > >> PRs
> > > >> > > >> > > > since they aren't the one listed, so I feel this will
> in
> > > the
> > > >> > > >> long-run
> > > >> > > >> > > > reduce the number of people doing code reviews.
> > > >> > > >> > > >
> > > >> > > >> > > > If there aren't enough people doing PR's, then people
> can
> > > >> > complain
> > > >> > > >> on
> > > >> > > >> > > dev@
> > > >> > > >> > > > asking for review.
> > > >> > > >> > > >
> > > >> > > >> > > > -Chris
> > > >> > > >> > > >
> > > >> > > >> > > >
> > > >> > > >> > > >
> > > >> > > >> > > >
> > > >> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> > > >> haibin@apache.org
> > > >> > >
> > > >> > > >> > wrote:
> > > >> > > >> > > >
> > > >> > > >> > > > > +1 (binding)
> > > >> > > >> > > > >
> > > >> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > > >> > > >> kellen.sunderland@gmail.com>
> > > >> > > >> > > > > wrote:
> > > >> > > >> > > > > > +1 (non-binding)
> > > >> > > >> > > > > >
> > > >> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > > >> > > >> steffenrochel@gmail.com
> > > >> > > >> > >
> > > >> > > >> > > > > wrote:
> > > >> > > >> > > > > >
> > > >> > > >> > > > > > > I propose to adopt the proposal.
> > > >> > > >> > > > > > > +1 (non-binding)
> > > >> > > >> > > > > > >
> > > >> > > >> > > > > > > Steffen
> > > >> > > >> > > > > > >
> > > >> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> > > >> muli.cmu@gmail.com
> > > >> > >
> > > >> > > >> > wrote:
> > > >> > > >> > > > > > >
> > > >> > > >> > > > > > > > Hi Isabel,
> > > >> > > >> > > > > > > >
> > > >> > > >> > > > > > > > My apologies that not saying that clearly.
> > > >> > > >> > > > > > > >
> > > >> > > >> > > > > > > > The purpose of this proposal is encouraging
> more
> > > >> > > >> contributors
> > > >> > > >> > to
> > > >> > > >> > > > help
> > > >> > > >> > > > > > > > review and merge PRs. And also hope to shorten
> > the
> > > >> time
> > > >> > > for
> > > >> > > >> a
> > > >> > > >> > PR
> > > >> > > >> > > to
> > > >> > > >> > > > > be
> > > >> > > >> > > > > > > > merged. After assigning maintainers to modules,
> > > then
> > > >> PR
> > > >> > > >> > > > contributors
> > > >> > > >> > > > > can
> > > >> > > >> > > > > > > > easily contact the reviewers. In other words,
> > > github
> > > >> > will
> > > >> > > >> > > > > automatically
> > > >> > > >> > > > > > > > assign the PR to the maintainer and send a
> > > >> notification
> > > >> > > >> email.
> > > >> > > >> > > > > > > >
> > > >> > > >> > > > > > > > I don't think I put the term "inbox" in my
> > > proposal.
> > > >> I
> > > >> > > never
> > > >> > > >> > > > > discussed
> > > >> > > >> > > > > > > PRs
> > > >> > > >> > > > > > > > with other contributors by sending email
> > directly,
> > > >> which
> > > >> > > is
> > > >> > > >> > less
> > > >> > > >> > > > > > > effective
> > > >> > > >> > > > > > > > than just using github. I also don't aware any
> > > other
> > > >> > > >> > contributor
> > > >> > > >> > > > use
> > > >> > > >> > > > > the
> > > >> > > >> > > > > > > > direct email way. So I didn't clarify it on the
> > > >> > proposal.
> > > >> > > >> > > > > > > >
> > > >> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel
> > > Drost-Fromm <
> > > >> > > >> > > > > isabel@apache.org>
> > > >> > > >> > > > > > > > wrote:
> > > >> > > >> > > > > > > >
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li
> <
> > > >> > > >> > > muli.cmu@gmail.com
> > > >> > > >> > > > >:
> > > >> > > >> > > > > > > > > >We should encourage to contract a specific
> > > >> > contributor
> > > >> > > >> for
> > > >> > > >> > > > issues
> > > >> > > >> > > > > and
> > > >> > > >> > > > > > > > > >PRs.
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > > My head translates "encourage to contact
> > specific
> > > >> > > >> > contributor"
> > > >> > > >> > > > into
> > > >> > > >> > > > > > > > > "encourage to contact specific contributors
> > > inbox".
> > > >> > This
> > > >> > > >> > > > translated
> > > >> > > >> > > > > > > > version
> > > >> > > >> > > > > > > > > is what I would highly discourage.
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > > See the disclaimer here for reasons behind
> > that:
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > > > Isabel
> > > >> > > >> > > > > > > > > --
> > > >> > > >> > > > > > > > > Diese Nachricht wurde von meinem
> Android-Gerät
> > > mit
> > > >> K-9
> > > >> > > >> Mail
> > > >> > > >> > > > > gesendet.
> > > >> > > >> > > > > > > > >
> > > >> > > >> > > > > > > >
> > > >> > > >> > > > > > >
> > > >> > > >> > > > > >
> > > >> > > >> > > > >
> > > >> > > >> > > >
> > > >> > > >> > >
> > > >> > > >> >
> > > >> > > >>
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Sandeep Krishnamurthy
> > > >
> > >
> > >
> > >
> > > --
> > > Sandeep Krishnamurthy
> > >
> >
>
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
I'm not sure I understand the "orphaned package" thing. You mean that no
one is reviewing them?
If a corporation wishes to assign a particular portion of the code to an
employee to review regularly, then that can take care of any portions
becoming "orphaned", but it can't mean "this person we assigned is now the
last word.
If someone takes an interest in reviewing a particular part of the code,
then they'd tend to add themself to the "watch list" (this CODEOWNERS
file), but I don't believe that this file should dictate how important one
committer's reviews are compared to another. You don't entice people to
review by telling them that their opinion is only worth half of person
X's. Why would they even bother? Committers are made committers because
they are trusted to behave competently and not merge stuff they aren't
comfortable with.
People work hard to become committers, but then saying that "ok you're a
committer but really only these 5 people get to merge code unless you jump
through all of these hoops" isn't fair, IMHO, and won't help to build the
community.
In addition, so far the mentors seem to have discouraged this sort of
"ownership" role.
On Sun, Jan 14, 2018 at 8:39 PM, Steffen Rochel <st...@gmail.com>
wrote:
> Sandeep -
> 1. Yes, but not only. Using maintainers the community will also know who is
> expert or point of contact for a specific package within the MXNet repo.
> 2. I suggested: By default the package maintainer should merge PR after
> appropriate review. A PR which received 2 +1 (or LGTM) comments can be
> merged by any committer.
> Of course, open to suggestion and I assume we all know when to apply common
> sense for small changes.
> As we are gaining more experience with a larger community we can decide if
> it make sense to use required reviews by the CODEOWNERS (could be one or
> more per package), but I think this would be to restrictive at this time.
>
> I liked the description from github
> <https://opensource.guide/leadership-and-governance/> about the role of a
> maintainer: "... Regardless of what they do day-to-day, a maintainer is
> probably someone who feels responsibility over the direction of the project
> and is committed to improving it. " I feel this does apply to the various
> packages/directories in MXNet to grow the community and project.
>
> Chris - can you please elaborate your concerns and suggest alternative? How
> can we ensure certain packages will not become orphans? I do see a
> maintainer as somebody with detailed knowledge who cares about an area and
> certainly not as dictator or king.
>
> Steffen
>
> On Sun, Jan 14, 2018 at 8:00 PM sandeep krishnamurthy <
> sandeep.krishna98@gmail.com> wrote:
>
> > Just wanted to clarify my understanding.
> > 1. We are going to use Github CODEOWNERS functionality as a feature for
> > getting notified.
> > 2. This does not mean only CODEOWNERS approved code will be merged for
> > respective module. (We need to evolve community to self-sustain without
> > getting blocked on one poc)
> >
> > Regards,
> > Sandeep
> >
> > On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
> > sandeep.krishna98@gmail.com> wrote:
> >
> > > +1 (binding) for suggestion around framing CODEOWNERS functionality as
> > the
> > > watchlist.
> > > I also feel that we should enable and find/request more than 1 person
> per
> > > module to help the project.
> > >
> > > But, still, if it is something like +1 or watch button for modules
> rather
> > > than a new PR to follow a topic, it would have been great. Something
> for
> > > future :-)
> > >
> > > Regards,
> > > Sandeep
> > >
> > > On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <
> steffenrochel@gmail.com
> > >
> > > wrote:
> > >
> > >> Thanks Chris for the great reading suggestion
> > >> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
> > >>
> > >> I'm suggesting that we adopt Mu's proposal to use github code owner
> > >> mechanism to identify designated maintainer for each package.
> > >> To address the concerns raised in this thread I proposed
> > >> to add into the header of the CODEOWNERS file
> > >> https://github.com/apache/incubator-mxnet/pull/9426
> > >> (changes below).
> > >>
> > >> Chris, Sebastian, Isabel - please suggest changes, but I hope I
> > addressed
> > >> your concerns.
> > >>
> > >> In the future we can also enable required reviews (see
> > >> https://help.github.com/articles/about-pull-request-reviews/), but I
> > >> would
> > >> suggest to make one change at a time.
> > >>
> > >> I do suggest we should explore how we can best adopt existing github
> > >> features before considering building additional CI tasks.
> > >>
> > >> Steffen
> > >>
> > >> # Please see documentation of use of CODEOWNERS file at
> > >> # https://help.github.com/articles/about-codeowners/ and
> > >> # https://github.com/blog/2392-introducing-code-owners
> > >> #
> > >> # The first owner listed for a package is considered the maintainer
> for
> > a
> > >> package.
> > >> # Anybody can add themselves or a team (see
> > >> https://help.github.com/articles/about-teams/)
> > >> # as additional owners to get notified about changes in a specific
> > >> package.
> > >> #
> > >> # By default the package maintainer should merge PR after appropriate
> > >> review.
> > >> # A PR which received 2 +1 (or LGTM) comments can be merged by any
> > >> committer.
> > >> # In the future we might consider adopting required reviews
> > >> # (see https://help.github.com/articles/about-pull-request-reviews/)
> > >>
> > >>
> > >> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <bhavinthaker@gmail.com
> >
> > >> wrote:
> > >>
> > >> > During the MXNet 1.0 release, there was feedback from the mentors
> and
> > >> folks
> > >> > in general@ to clarify at the top of the CODEOWNERs file on what
> the
> > >> > contents of this file meant.
> > >> >
> > >> > Hi Mu,
> > >> >
> > >> > Please add the description of the file in the file header. I expect
> > that
> > >> > this will be a requirement for the next MXNet release 1.0.1.
> > >> >
> > >> > Thanks,
> > >> > Bhavin Thaker.
> > >> >
> > >> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <
> cjolivier01@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > i’d be +1 if CODEOWNERS file has a big note at the top saying
> > >> basically
> > >> > > it’s just for watching code changes that you’d like to know about
> > (to
> > >> > > review or just to follow) and that anyone can add themself.
> > >> > >
> > >> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <
> > cjolivier01@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Does it have to be called "CODEOWNERS"? I would be more
> > comfortable
> > >> > with
> > >> > > > it if it's a "watch list" where it just means you wish to watch
> > code
> > >> > here
> > >> > > > or there in the source structure and anyone can add or remove
> > their
> > >> > name
> > >> > > > from watching some part of the code at any time.
> > >> > > >
> > >> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > >> > > > marco.g.abreu@googlemail.com> wrote:
> > >> > > >
> > >> > > >> I agree. How about we find another way to allow people to
> > subscribe
> > >> > for
> > >> > > >> changes in a specific file or directory?
> > >> > > >>
> > >> > > >> -Marco
> > >> > > >>
> > >> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > >> > > cjolivier01@gmail.com
> > >> > > >> >:
> > >> > > >>
> > >> > > >> > Have you read "The Cathedral and the Bazaar"?
> > >> > > >> >
> > >> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > >> > > >> >
> > >> > > >> > One of the points I took from this is that once a project
> finds
> > >> its
> > >> > > >> stride,
> > >> > > >> > it actually runs more efficiently without centralization than
> > >> with.
> > >> > > >> >
> > >> > > >> > -Chris
> > >> > > >> >
> > >> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > >> > > >> > marco.g.abreu@googlemail.com> wrote:
> > >> > > >> >
> > >> > > >> > > Hi Chris,
> > >> > > >> > >
> > >> > > >> > > you have a good point about people being afraid of
> reviewing
> > >> PRs
> > >> > > which
> > >> > > >> > they
> > >> > > >> > > are not assigned to and I totally agree that we should
> > >> encourage
> > >> > > >> > everybody
> > >> > > >> > > to review PRs.
> > >> > > >> > >
> > >> > > >> > > One important advantage I see in this is the notification:
> > >> since
> > >> > we
> > >> > > >> are
> > >> > > >> > not
> > >> > > >> > > using the feature to required an approval, this step is
> > >> entirely
> > >> > for
> > >> > > >> > > information purpose. I, for example, would like to get
> > notified
> > >> > if a
> > >> > > >> PR
> > >> > > >> > to
> > >> > > >> > > change a CI file would be created. Just as an example: over
> > >> > > >> Christmas, a
> > >> > > >> > PR
> > >> > > >> > > to update mkl has been pushed without me knowing about it.
> > >> > Somehow,
> > >> > > >> after
> > >> > > >> > > my vacation, we started to get issues with mkl test - I
> only
> > >> found
> > >> > > out
> > >> > > >> > > about this PR after quite a long investigation. If we would
> > >> extend
> > >> > > the
> > >> > > >> > > usage of the code maintainers, we'll make sure that changes
> > >> like
> > >> > > these
> > >> > > >> > will
> > >> > > >> > > notify the people who have the best knowledge about that
> > part.
> > >> > > >> > >
> > >> > > >> > > Marco
> > >> > > >> > >
> > >> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > >> > > >> cjolivier01@gmail.com
> > >> > > >> > >:
> > >> > > >> > >
> > >> > > >> > > > -1 (binding)
> > >> > > >> > > >
> > >> > > >> > > > I totally understand the motivation for this (I've
> > definitely
> > >> > > saved
> > >> > > >> > > myself
> > >> > > >> > > > some grief by getting called out automatically for
> > >> > CMakeLists.txt
> > >> > > >> > stuff,
> > >> > > >> > > > for example), but I respectfully decline for the
> following
> > >> > > >> reason(s):
> > >> > > >> > > >
> > >> > > >> > > > I feel that defining code-owners has some negative
> effects.
> > >> > > >> > > >
> > >> > > >> > > > Other committers may be reluctant to start reviewing and
> > >> > approving
> > >> > > >> PRs
> > >> > > >> > > > since they aren't the one listed, so I feel this will in
> > the
> > >> > > >> long-run
> > >> > > >> > > > reduce the number of people doing code reviews.
> > >> > > >> > > >
> > >> > > >> > > > If there aren't enough people doing PR's, then people can
> > >> > complain
> > >> > > >> on
> > >> > > >> > > dev@
> > >> > > >> > > > asking for review.
> > >> > > >> > > >
> > >> > > >> > > > -Chris
> > >> > > >> > > >
> > >> > > >> > > >
> > >> > > >> > > >
> > >> > > >> > > >
> > >> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> > >> haibin@apache.org
> > >> > >
> > >> > > >> > wrote:
> > >> > > >> > > >
> > >> > > >> > > > > +1 (binding)
> > >> > > >> > > > >
> > >> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > >> > > >> kellen.sunderland@gmail.com>
> > >> > > >> > > > > wrote:
> > >> > > >> > > > > > +1 (non-binding)
> > >> > > >> > > > > >
> > >> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > >> > > >> steffenrochel@gmail.com
> > >> > > >> > >
> > >> > > >> > > > > wrote:
> > >> > > >> > > > > >
> > >> > > >> > > > > > > I propose to adopt the proposal.
> > >> > > >> > > > > > > +1 (non-binding)
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > Steffen
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> > >> muli.cmu@gmail.com
> > >> > >
> > >> > > >> > wrote:
> > >> > > >> > > > > > >
> > >> > > >> > > > > > > > Hi Isabel,
> > >> > > >> > > > > > > >
> > >> > > >> > > > > > > > My apologies that not saying that clearly.
> > >> > > >> > > > > > > >
> > >> > > >> > > > > > > > The purpose of this proposal is encouraging more
> > >> > > >> contributors
> > >> > > >> > to
> > >> > > >> > > > help
> > >> > > >> > > > > > > > review and merge PRs. And also hope to shorten
> the
> > >> time
> > >> > > for
> > >> > > >> a
> > >> > > >> > PR
> > >> > > >> > > to
> > >> > > >> > > > > be
> > >> > > >> > > > > > > > merged. After assigning maintainers to modules,
> > then
> > >> PR
> > >> > > >> > > > contributors
> > >> > > >> > > > > can
> > >> > > >> > > > > > > > easily contact the reviewers. In other words,
> > github
> > >> > will
> > >> > > >> > > > > automatically
> > >> > > >> > > > > > > > assign the PR to the maintainer and send a
> > >> notification
> > >> > > >> email.
> > >> > > >> > > > > > > >
> > >> > > >> > > > > > > > I don't think I put the term "inbox" in my
> > proposal.
> > >> I
> > >> > > never
> > >> > > >> > > > > discussed
> > >> > > >> > > > > > > PRs
> > >> > > >> > > > > > > > with other contributors by sending email
> directly,
> > >> which
> > >> > > is
> > >> > > >> > less
> > >> > > >> > > > > > > effective
> > >> > > >> > > > > > > > than just using github. I also don't aware any
> > other
> > >> > > >> > contributor
> > >> > > >> > > > use
> > >> > > >> > > > > the
> > >> > > >> > > > > > > > direct email way. So I didn't clarify it on the
> > >> > proposal.
> > >> > > >> > > > > > > >
> > >> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel
> > Drost-Fromm <
> > >> > > >> > > > > isabel@apache.org>
> > >> > > >> > > > > > > > wrote:
> > >> > > >> > > > > > > >
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > >> > > >> > > muli.cmu@gmail.com
> > >> > > >> > > > >:
> > >> > > >> > > > > > > > > >We should encourage to contract a specific
> > >> > contributor
> > >> > > >> for
> > >> > > >> > > > issues
> > >> > > >> > > > > and
> > >> > > >> > > > > > > > > >PRs.
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > > My head translates "encourage to contact
> specific
> > >> > > >> > contributor"
> > >> > > >> > > > into
> > >> > > >> > > > > > > > > "encourage to contact specific contributors
> > inbox".
> > >> > This
> > >> > > >> > > > translated
> > >> > > >> > > > > > > > version
> > >> > > >> > > > > > > > > is what I would highly discourage.
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > > See the disclaimer here for reasons behind
> that:
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > > > Isabel
> > >> > > >> > > > > > > > > --
> > >> > > >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät
> > mit
> > >> K-9
> > >> > > >> Mail
> > >> > > >> > > > > gesendet.
> > >> > > >> > > > > > > > >
> > >> > > >> > > > > > > >
> > >> > > >> > > > > > >
> > >> > > >> > > > > >
> > >> > > >> > > > >
> > >> > > >> > > >
> > >> > > >> > >
> > >> > > >> >
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Sandeep Krishnamurthy
> > >
> >
> >
> >
> > --
> > Sandeep Krishnamurthy
> >
>
Re: Module maintainers proposal
Posted by Steffen Rochel <st...@gmail.com>.
Sandeep -
1. Yes, but not only. Using maintainers the community will also know who is
expert or point of contact for a specific package within the MXNet repo.
2. I suggested: By default the package maintainer should merge PR after
appropriate review. A PR which received 2 +1 (or LGTM) comments can be
merged by any committer.
Of course, open to suggestion and I assume we all know when to apply common
sense for small changes.
As we are gaining more experience with a larger community we can decide if
it make sense to use required reviews by the CODEOWNERS (could be one or
more per package), but I think this would be to restrictive at this time.
I liked the description from github
<https://opensource.guide/leadership-and-governance/> about the role of a
maintainer: "... Regardless of what they do day-to-day, a maintainer is
probably someone who feels responsibility over the direction of the project
and is committed to improving it. " I feel this does apply to the various
packages/directories in MXNet to grow the community and project.
Chris - can you please elaborate your concerns and suggest alternative? How
can we ensure certain packages will not become orphans? I do see a
maintainer as somebody with detailed knowledge who cares about an area and
certainly not as dictator or king.
Steffen
On Sun, Jan 14, 2018 at 8:00 PM sandeep krishnamurthy <
sandeep.krishna98@gmail.com> wrote:
> Just wanted to clarify my understanding.
> 1. We are going to use Github CODEOWNERS functionality as a feature for
> getting notified.
> 2. This does not mean only CODEOWNERS approved code will be merged for
> respective module. (We need to evolve community to self-sustain without
> getting blocked on one poc)
>
> Regards,
> Sandeep
>
> On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
> sandeep.krishna98@gmail.com> wrote:
>
> > +1 (binding) for suggestion around framing CODEOWNERS functionality as
> the
> > watchlist.
> > I also feel that we should enable and find/request more than 1 person per
> > module to help the project.
> >
> > But, still, if it is something like +1 or watch button for modules rather
> > than a new PR to follow a topic, it would have been great. Something for
> > future :-)
> >
> > Regards,
> > Sandeep
> >
> > On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <steffenrochel@gmail.com
> >
> > wrote:
> >
> >> Thanks Chris for the great reading suggestion
> >> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
> >>
> >> I'm suggesting that we adopt Mu's proposal to use github code owner
> >> mechanism to identify designated maintainer for each package.
> >> To address the concerns raised in this thread I proposed
> >> to add into the header of the CODEOWNERS file
> >> https://github.com/apache/incubator-mxnet/pull/9426
> >> (changes below).
> >>
> >> Chris, Sebastian, Isabel - please suggest changes, but I hope I
> addressed
> >> your concerns.
> >>
> >> In the future we can also enable required reviews (see
> >> https://help.github.com/articles/about-pull-request-reviews/), but I
> >> would
> >> suggest to make one change at a time.
> >>
> >> I do suggest we should explore how we can best adopt existing github
> >> features before considering building additional CI tasks.
> >>
> >> Steffen
> >>
> >> # Please see documentation of use of CODEOWNERS file at
> >> # https://help.github.com/articles/about-codeowners/ and
> >> # https://github.com/blog/2392-introducing-code-owners
> >> #
> >> # The first owner listed for a package is considered the maintainer for
> a
> >> package.
> >> # Anybody can add themselves or a team (see
> >> https://help.github.com/articles/about-teams/)
> >> # as additional owners to get notified about changes in a specific
> >> package.
> >> #
> >> # By default the package maintainer should merge PR after appropriate
> >> review.
> >> # A PR which received 2 +1 (or LGTM) comments can be merged by any
> >> committer.
> >> # In the future we might consider adopting required reviews
> >> # (see https://help.github.com/articles/about-pull-request-reviews/)
> >>
> >>
> >> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <bh...@gmail.com>
> >> wrote:
> >>
> >> > During the MXNet 1.0 release, there was feedback from the mentors and
> >> folks
> >> > in general@ to clarify at the top of the CODEOWNERs file on what the
> >> > contents of this file meant.
> >> >
> >> > Hi Mu,
> >> >
> >> > Please add the description of the file in the file header. I expect
> that
> >> > this will be a requirement for the next MXNet release 1.0.1.
> >> >
> >> > Thanks,
> >> > Bhavin Thaker.
> >> >
> >> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <cj...@gmail.com>
> >> > wrote:
> >> >
> >> > > i’d be +1 if CODEOWNERS file has a big note at the top saying
> >> basically
> >> > > it’s just for watching code changes that you’d like to know about
> (to
> >> > > review or just to follow) and that anyone can add themself.
> >> > >
> >> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <
> cjolivier01@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Does it have to be called "CODEOWNERS"? I would be more
> comfortable
> >> > with
> >> > > > it if it's a "watch list" where it just means you wish to watch
> code
> >> > here
> >> > > > or there in the source structure and anyone can add or remove
> their
> >> > name
> >> > > > from watching some part of the code at any time.
> >> > > >
> >> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> >> > > > marco.g.abreu@googlemail.com> wrote:
> >> > > >
> >> > > >> I agree. How about we find another way to allow people to
> subscribe
> >> > for
> >> > > >> changes in a specific file or directory?
> >> > > >>
> >> > > >> -Marco
> >> > > >>
> >> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> >> > > cjolivier01@gmail.com
> >> > > >> >:
> >> > > >>
> >> > > >> > Have you read "The Cathedral and the Bazaar"?
> >> > > >> >
> >> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> >> > > >> >
> >> > > >> > One of the points I took from this is that once a project finds
> >> its
> >> > > >> stride,
> >> > > >> > it actually runs more efficiently without centralization than
> >> with.
> >> > > >> >
> >> > > >> > -Chris
> >> > > >> >
> >> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> >> > > >> > marco.g.abreu@googlemail.com> wrote:
> >> > > >> >
> >> > > >> > > Hi Chris,
> >> > > >> > >
> >> > > >> > > you have a good point about people being afraid of reviewing
> >> PRs
> >> > > which
> >> > > >> > they
> >> > > >> > > are not assigned to and I totally agree that we should
> >> encourage
> >> > > >> > everybody
> >> > > >> > > to review PRs.
> >> > > >> > >
> >> > > >> > > One important advantage I see in this is the notification:
> >> since
> >> > we
> >> > > >> are
> >> > > >> > not
> >> > > >> > > using the feature to required an approval, this step is
> >> entirely
> >> > for
> >> > > >> > > information purpose. I, for example, would like to get
> notified
> >> > if a
> >> > > >> PR
> >> > > >> > to
> >> > > >> > > change a CI file would be created. Just as an example: over
> >> > > >> Christmas, a
> >> > > >> > PR
> >> > > >> > > to update mkl has been pushed without me knowing about it.
> >> > Somehow,
> >> > > >> after
> >> > > >> > > my vacation, we started to get issues with mkl test - I only
> >> found
> >> > > out
> >> > > >> > > about this PR after quite a long investigation. If we would
> >> extend
> >> > > the
> >> > > >> > > usage of the code maintainers, we'll make sure that changes
> >> like
> >> > > these
> >> > > >> > will
> >> > > >> > > notify the people who have the best knowledge about that
> part.
> >> > > >> > >
> >> > > >> > > Marco
> >> > > >> > >
> >> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> >> > > >> cjolivier01@gmail.com
> >> > > >> > >:
> >> > > >> > >
> >> > > >> > > > -1 (binding)
> >> > > >> > > >
> >> > > >> > > > I totally understand the motivation for this (I've
> definitely
> >> > > saved
> >> > > >> > > myself
> >> > > >> > > > some grief by getting called out automatically for
> >> > CMakeLists.txt
> >> > > >> > stuff,
> >> > > >> > > > for example), but I respectfully decline for the following
> >> > > >> reason(s):
> >> > > >> > > >
> >> > > >> > > > I feel that defining code-owners has some negative effects.
> >> > > >> > > >
> >> > > >> > > > Other committers may be reluctant to start reviewing and
> >> > approving
> >> > > >> PRs
> >> > > >> > > > since they aren't the one listed, so I feel this will in
> the
> >> > > >> long-run
> >> > > >> > > > reduce the number of people doing code reviews.
> >> > > >> > > >
> >> > > >> > > > If there aren't enough people doing PR's, then people can
> >> > complain
> >> > > >> on
> >> > > >> > > dev@
> >> > > >> > > > asking for review.
> >> > > >> > > >
> >> > > >> > > > -Chris
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> >> haibin@apache.org
> >> > >
> >> > > >> > wrote:
> >> > > >> > > >
> >> > > >> > > > > +1 (binding)
> >> > > >> > > > >
> >> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> >> > > >> kellen.sunderland@gmail.com>
> >> > > >> > > > > wrote:
> >> > > >> > > > > > +1 (non-binding)
> >> > > >> > > > > >
> >> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> >> > > >> steffenrochel@gmail.com
> >> > > >> > >
> >> > > >> > > > > wrote:
> >> > > >> > > > > >
> >> > > >> > > > > > > I propose to adopt the proposal.
> >> > > >> > > > > > > +1 (non-binding)
> >> > > >> > > > > > >
> >> > > >> > > > > > > Steffen
> >> > > >> > > > > > >
> >> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> >> muli.cmu@gmail.com
> >> > >
> >> > > >> > wrote:
> >> > > >> > > > > > >
> >> > > >> > > > > > > > Hi Isabel,
> >> > > >> > > > > > > >
> >> > > >> > > > > > > > My apologies that not saying that clearly.
> >> > > >> > > > > > > >
> >> > > >> > > > > > > > The purpose of this proposal is encouraging more
> >> > > >> contributors
> >> > > >> > to
> >> > > >> > > > help
> >> > > >> > > > > > > > review and merge PRs. And also hope to shorten the
> >> time
> >> > > for
> >> > > >> a
> >> > > >> > PR
> >> > > >> > > to
> >> > > >> > > > > be
> >> > > >> > > > > > > > merged. After assigning maintainers to modules,
> then
> >> PR
> >> > > >> > > > contributors
> >> > > >> > > > > can
> >> > > >> > > > > > > > easily contact the reviewers. In other words,
> github
> >> > will
> >> > > >> > > > > automatically
> >> > > >> > > > > > > > assign the PR to the maintainer and send a
> >> notification
> >> > > >> email.
> >> > > >> > > > > > > >
> >> > > >> > > > > > > > I don't think I put the term "inbox" in my
> proposal.
> >> I
> >> > > never
> >> > > >> > > > > discussed
> >> > > >> > > > > > > PRs
> >> > > >> > > > > > > > with other contributors by sending email directly,
> >> which
> >> > > is
> >> > > >> > less
> >> > > >> > > > > > > effective
> >> > > >> > > > > > > > than just using github. I also don't aware any
> other
> >> > > >> > contributor
> >> > > >> > > > use
> >> > > >> > > > > the
> >> > > >> > > > > > > > direct email way. So I didn't clarify it on the
> >> > proposal.
> >> > > >> > > > > > > >
> >> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel
> Drost-Fromm <
> >> > > >> > > > > isabel@apache.org>
> >> > > >> > > > > > > > wrote:
> >> > > >> > > > > > > >
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> >> > > >> > > muli.cmu@gmail.com
> >> > > >> > > > >:
> >> > > >> > > > > > > > > >We should encourage to contract a specific
> >> > contributor
> >> > > >> for
> >> > > >> > > > issues
> >> > > >> > > > > and
> >> > > >> > > > > > > > > >PRs.
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > > My head translates "encourage to contact specific
> >> > > >> > contributor"
> >> > > >> > > > into
> >> > > >> > > > > > > > > "encourage to contact specific contributors
> inbox".
> >> > This
> >> > > >> > > > translated
> >> > > >> > > > > > > > version
> >> > > >> > > > > > > > > is what I would highly discourage.
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > > See the disclaimer here for reasons behind that:
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > > > Isabel
> >> > > >> > > > > > > > > --
> >> > > >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät
> mit
> >> K-9
> >> > > >> Mail
> >> > > >> > > > > gesendet.
> >> > > >> > > > > > > > >
> >> > > >> > > > > > > >
> >> > > >> > > > > > >
> >> > > >> > > > > >
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > >
> >> > > >> >
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Sandeep Krishnamurthy
> >
>
>
>
> --
> Sandeep Krishnamurthy
>
Re: Module maintainers proposal
Posted by sandeep krishnamurthy <sa...@gmail.com>.
Just wanted to clarify my understanding.
1. We are going to use Github CODEOWNERS functionality as a feature for
getting notified.
2. This does not mean only CODEOWNERS approved code will be merged for
respective module. (We need to evolve community to self-sustain without
getting blocked on one poc)
Regards,
Sandeep
On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
sandeep.krishna98@gmail.com> wrote:
> +1 (binding) for suggestion around framing CODEOWNERS functionality as the
> watchlist.
> I also feel that we should enable and find/request more than 1 person per
> module to help the project.
>
> But, still, if it is something like +1 or watch button for modules rather
> than a new PR to follow a topic, it would have been great. Something for
> future :-)
>
> Regards,
> Sandeep
>
> On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <st...@gmail.com>
> wrote:
>
>> Thanks Chris for the great reading suggestion
>> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
>>
>> I'm suggesting that we adopt Mu's proposal to use github code owner
>> mechanism to identify designated maintainer for each package.
>> To address the concerns raised in this thread I proposed
>> to add into the header of the CODEOWNERS file
>> https://github.com/apache/incubator-mxnet/pull/9426
>> (changes below).
>>
>> Chris, Sebastian, Isabel - please suggest changes, but I hope I addressed
>> your concerns.
>>
>> In the future we can also enable required reviews (see
>> https://help.github.com/articles/about-pull-request-reviews/), but I
>> would
>> suggest to make one change at a time.
>>
>> I do suggest we should explore how we can best adopt existing github
>> features before considering building additional CI tasks.
>>
>> Steffen
>>
>> # Please see documentation of use of CODEOWNERS file at
>> # https://help.github.com/articles/about-codeowners/ and
>> # https://github.com/blog/2392-introducing-code-owners
>> #
>> # The first owner listed for a package is considered the maintainer for a
>> package.
>> # Anybody can add themselves or a team (see
>> https://help.github.com/articles/about-teams/)
>> # as additional owners to get notified about changes in a specific
>> package.
>> #
>> # By default the package maintainer should merge PR after appropriate
>> review.
>> # A PR which received 2 +1 (or LGTM) comments can be merged by any
>> committer.
>> # In the future we might consider adopting required reviews
>> # (see https://help.github.com/articles/about-pull-request-reviews/)
>>
>>
>> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <bh...@gmail.com>
>> wrote:
>>
>> > During the MXNet 1.0 release, there was feedback from the mentors and
>> folks
>> > in general@ to clarify at the top of the CODEOWNERs file on what the
>> > contents of this file meant.
>> >
>> > Hi Mu,
>> >
>> > Please add the description of the file in the file header. I expect that
>> > this will be a requirement for the next MXNet release 1.0.1.
>> >
>> > Thanks,
>> > Bhavin Thaker.
>> >
>> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <cj...@gmail.com>
>> > wrote:
>> >
>> > > i’d be +1 if CODEOWNERS file has a big note at the top saying
>> basically
>> > > it’s just for watching code changes that you’d like to know about (to
>> > > review or just to follow) and that anyone can add themself.
>> > >
>> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <cj...@gmail.com>
>> > > wrote:
>> > >
>> > > > Does it have to be called "CODEOWNERS"? I would be more comfortable
>> > with
>> > > > it if it's a "watch list" where it just means you wish to watch code
>> > here
>> > > > or there in the source structure and anyone can add or remove their
>> > name
>> > > > from watching some part of the code at any time.
>> > > >
>> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
>> > > > marco.g.abreu@googlemail.com> wrote:
>> > > >
>> > > >> I agree. How about we find another way to allow people to subscribe
>> > for
>> > > >> changes in a specific file or directory?
>> > > >>
>> > > >> -Marco
>> > > >>
>> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
>> > > cjolivier01@gmail.com
>> > > >> >:
>> > > >>
>> > > >> > Have you read "The Cathedral and the Bazaar"?
>> > > >> >
>> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
>> > > >> >
>> > > >> > One of the points I took from this is that once a project finds
>> its
>> > > >> stride,
>> > > >> > it actually runs more efficiently without centralization than
>> with.
>> > > >> >
>> > > >> > -Chris
>> > > >> >
>> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
>> > > >> > marco.g.abreu@googlemail.com> wrote:
>> > > >> >
>> > > >> > > Hi Chris,
>> > > >> > >
>> > > >> > > you have a good point about people being afraid of reviewing
>> PRs
>> > > which
>> > > >> > they
>> > > >> > > are not assigned to and I totally agree that we should
>> encourage
>> > > >> > everybody
>> > > >> > > to review PRs.
>> > > >> > >
>> > > >> > > One important advantage I see in this is the notification:
>> since
>> > we
>> > > >> are
>> > > >> > not
>> > > >> > > using the feature to required an approval, this step is
>> entirely
>> > for
>> > > >> > > information purpose. I, for example, would like to get notified
>> > if a
>> > > >> PR
>> > > >> > to
>> > > >> > > change a CI file would be created. Just as an example: over
>> > > >> Christmas, a
>> > > >> > PR
>> > > >> > > to update mkl has been pushed without me knowing about it.
>> > Somehow,
>> > > >> after
>> > > >> > > my vacation, we started to get issues with mkl test - I only
>> found
>> > > out
>> > > >> > > about this PR after quite a long investigation. If we would
>> extend
>> > > the
>> > > >> > > usage of the code maintainers, we'll make sure that changes
>> like
>> > > these
>> > > >> > will
>> > > >> > > notify the people who have the best knowledge about that part.
>> > > >> > >
>> > > >> > > Marco
>> > > >> > >
>> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
>> > > >> cjolivier01@gmail.com
>> > > >> > >:
>> > > >> > >
>> > > >> > > > -1 (binding)
>> > > >> > > >
>> > > >> > > > I totally understand the motivation for this (I've definitely
>> > > saved
>> > > >> > > myself
>> > > >> > > > some grief by getting called out automatically for
>> > CMakeLists.txt
>> > > >> > stuff,
>> > > >> > > > for example), but I respectfully decline for the following
>> > > >> reason(s):
>> > > >> > > >
>> > > >> > > > I feel that defining code-owners has some negative effects.
>> > > >> > > >
>> > > >> > > > Other committers may be reluctant to start reviewing and
>> > approving
>> > > >> PRs
>> > > >> > > > since they aren't the one listed, so I feel this will in the
>> > > >> long-run
>> > > >> > > > reduce the number of people doing code reviews.
>> > > >> > > >
>> > > >> > > > If there aren't enough people doing PR's, then people can
>> > complain
>> > > >> on
>> > > >> > > dev@
>> > > >> > > > asking for review.
>> > > >> > > >
>> > > >> > > > -Chris
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
>> haibin@apache.org
>> > >
>> > > >> > wrote:
>> > > >> > > >
>> > > >> > > > > +1 (binding)
>> > > >> > > > >
>> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
>> > > >> kellen.sunderland@gmail.com>
>> > > >> > > > > wrote:
>> > > >> > > > > > +1 (non-binding)
>> > > >> > > > > >
>> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
>> > > >> steffenrochel@gmail.com
>> > > >> > >
>> > > >> > > > > wrote:
>> > > >> > > > > >
>> > > >> > > > > > > I propose to adopt the proposal.
>> > > >> > > > > > > +1 (non-binding)
>> > > >> > > > > > >
>> > > >> > > > > > > Steffen
>> > > >> > > > > > >
>> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
>> muli.cmu@gmail.com
>> > >
>> > > >> > wrote:
>> > > >> > > > > > >
>> > > >> > > > > > > > Hi Isabel,
>> > > >> > > > > > > >
>> > > >> > > > > > > > My apologies that not saying that clearly.
>> > > >> > > > > > > >
>> > > >> > > > > > > > The purpose of this proposal is encouraging more
>> > > >> contributors
>> > > >> > to
>> > > >> > > > help
>> > > >> > > > > > > > review and merge PRs. And also hope to shorten the
>> time
>> > > for
>> > > >> a
>> > > >> > PR
>> > > >> > > to
>> > > >> > > > > be
>> > > >> > > > > > > > merged. After assigning maintainers to modules, then
>> PR
>> > > >> > > > contributors
>> > > >> > > > > can
>> > > >> > > > > > > > easily contact the reviewers. In other words, github
>> > will
>> > > >> > > > > automatically
>> > > >> > > > > > > > assign the PR to the maintainer and send a
>> notification
>> > > >> email.
>> > > >> > > > > > > >
>> > > >> > > > > > > > I don't think I put the term "inbox" in my proposal.
>> I
>> > > never
>> > > >> > > > > discussed
>> > > >> > > > > > > PRs
>> > > >> > > > > > > > with other contributors by sending email directly,
>> which
>> > > is
>> > > >> > less
>> > > >> > > > > > > effective
>> > > >> > > > > > > > than just using github. I also don't aware any other
>> > > >> > contributor
>> > > >> > > > use
>> > > >> > > > > the
>> > > >> > > > > > > > direct email way. So I didn't clarify it on the
>> > proposal.
>> > > >> > > > > > > >
>> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
>> > > >> > > > > isabel@apache.org>
>> > > >> > > > > > > > wrote:
>> > > >> > > > > > > >
>> > > >> > > > > > > > >
>> > > >> > > > > > > > >
>> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
>> > > >> > > muli.cmu@gmail.com
>> > > >> > > > >:
>> > > >> > > > > > > > > >We should encourage to contract a specific
>> > contributor
>> > > >> for
>> > > >> > > > issues
>> > > >> > > > > and
>> > > >> > > > > > > > > >PRs.
>> > > >> > > > > > > > >
>> > > >> > > > > > > > > My head translates "encourage to contact specific
>> > > >> > contributor"
>> > > >> > > > into
>> > > >> > > > > > > > > "encourage to contact specific contributors inbox".
>> > This
>> > > >> > > > translated
>> > > >> > > > > > > > version
>> > > >> > > > > > > > > is what I would highly discourage.
>> > > >> > > > > > > > >
>> > > >> > > > > > > > > See the disclaimer here for reasons behind that:
>> > > >> > > > > > > > >
>> > > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
>> > > >> > > > > > > > >
>> > > >> > > > > > > > >
>> > > >> > > > > > > > > Isabel
>> > > >> > > > > > > > > --
>> > > >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit
>> K-9
>> > > >> Mail
>> > > >> > > > > gesendet.
>> > > >> > > > > > > > >
>> > > >> > > > > > > >
>> > > >> > > > > > >
>> > > >> > > > > >
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Sandeep Krishnamurthy
>
--
Sandeep Krishnamurthy
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
+1 for the line: # Anybody can add themselves
-1 for all of the other lines, which revolve mostly around who is
Maintainer/King of this part of the code or that, and rules for merging.
Responsible committers can take it on a case-by-case basis.
On Sun, Jan 14, 2018 at 7:43 PM, sandeep krishnamurthy <
sandeep.krishna98@gmail.com> wrote:
> +1 (binding) for suggestion around framing CODEOWNERS functionality as the
> watchlist.
> I also feel that we should enable and find/request more than 1 person per
> module to help the project.
>
> But, still, if it is something like +1 or watch button for modules rather
> than a new PR to follow a topic, it would have been great. Something for
> future :-)
>
> Regards,
> Sandeep
>
> On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <st...@gmail.com>
> wrote:
>
> > Thanks Chris for the great reading suggestion
> > <http://www.unterstein.net/su/docs/CathBaz.pdf>!
> >
> > I'm suggesting that we adopt Mu's proposal to use github code owner
> > mechanism to identify designated maintainer for each package.
> > To address the concerns raised in this thread I proposed
> > to add into the header of the CODEOWNERS file
> > https://github.com/apache/incubator-mxnet/pull/9426
> > (changes below).
> >
> > Chris, Sebastian, Isabel - please suggest changes, but I hope I addressed
> > your concerns.
> >
> > In the future we can also enable required reviews (see
> > https://help.github.com/articles/about-pull-request-reviews/), but I
> would
> > suggest to make one change at a time.
> >
> > I do suggest we should explore how we can best adopt existing github
> > features before considering building additional CI tasks.
> >
> > Steffen
> >
> > # Please see documentation of use of CODEOWNERS file at
> > # https://help.github.com/articles/about-codeowners/ and
> > # https://github.com/blog/2392-introducing-code-owners
> > #
> > # The first owner listed for a package is considered the maintainer for a
> > package.
> > # Anybody can add themselves or a team (see
> > https://help.github.com/articles/about-teams/)
> > # as additional owners to get notified about changes in a specific
> package.
> > #
> > # By default the package maintainer should merge PR after appropriate
> > review.
> > # A PR which received 2 +1 (or LGTM) comments can be merged by any
> > committer.
> > # In the future we might consider adopting required reviews
> > # (see https://help.github.com/articles/about-pull-request-reviews/)
> >
> >
> > On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <bh...@gmail.com>
> > wrote:
> >
> > > During the MXNet 1.0 release, there was feedback from the mentors and
> > folks
> > > in general@ to clarify at the top of the CODEOWNERs file on what the
> > > contents of this file meant.
> > >
> > > Hi Mu,
> > >
> > > Please add the description of the file in the file header. I expect
> that
> > > this will be a requirement for the next MXNet release 1.0.1.
> > >
> > > Thanks,
> > > Bhavin Thaker.
> > >
> > > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <cj...@gmail.com>
> > > wrote:
> > >
> > > > i’d be +1 if CODEOWNERS file has a big note at the top saying
> basically
> > > > it’s just for watching code changes that you’d like to know about (to
> > > > review or just to follow) and that anyone can add themself.
> > > >
> > > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <cjolivier01@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Does it have to be called "CODEOWNERS"? I would be more comfortable
> > > with
> > > > > it if it's a "watch list" where it just means you wish to watch
> code
> > > here
> > > > > or there in the source structure and anyone can add or remove their
> > > name
> > > > > from watching some part of the code at any time.
> > > > >
> > > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > > > > marco.g.abreu@googlemail.com> wrote:
> > > > >
> > > > >> I agree. How about we find another way to allow people to
> subscribe
> > > for
> > > > >> changes in a specific file or directory?
> > > > >>
> > > > >> -Marco
> > > > >>
> > > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > > > cjolivier01@gmail.com
> > > > >> >:
> > > > >>
> > > > >> > Have you read "The Cathedral and the Bazaar"?
> > > > >> >
> > > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > > > >> >
> > > > >> > One of the points I took from this is that once a project finds
> > its
> > > > >> stride,
> > > > >> > it actually runs more efficiently without centralization than
> > with.
> > > > >> >
> > > > >> > -Chris
> > > > >> >
> > > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > > > >> > marco.g.abreu@googlemail.com> wrote:
> > > > >> >
> > > > >> > > Hi Chris,
> > > > >> > >
> > > > >> > > you have a good point about people being afraid of reviewing
> PRs
> > > > which
> > > > >> > they
> > > > >> > > are not assigned to and I totally agree that we should
> encourage
> > > > >> > everybody
> > > > >> > > to review PRs.
> > > > >> > >
> > > > >> > > One important advantage I see in this is the notification:
> since
> > > we
> > > > >> are
> > > > >> > not
> > > > >> > > using the feature to required an approval, this step is
> entirely
> > > for
> > > > >> > > information purpose. I, for example, would like to get
> notified
> > > if a
> > > > >> PR
> > > > >> > to
> > > > >> > > change a CI file would be created. Just as an example: over
> > > > >> Christmas, a
> > > > >> > PR
> > > > >> > > to update mkl has been pushed without me knowing about it.
> > > Somehow,
> > > > >> after
> > > > >> > > my vacation, we started to get issues with mkl test - I only
> > found
> > > > out
> > > > >> > > about this PR after quite a long investigation. If we would
> > extend
> > > > the
> > > > >> > > usage of the code maintainers, we'll make sure that changes
> like
> > > > these
> > > > >> > will
> > > > >> > > notify the people who have the best knowledge about that part.
> > > > >> > >
> > > > >> > > Marco
> > > > >> > >
> > > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > > > >> cjolivier01@gmail.com
> > > > >> > >:
> > > > >> > >
> > > > >> > > > -1 (binding)
> > > > >> > > >
> > > > >> > > > I totally understand the motivation for this (I've
> definitely
> > > > saved
> > > > >> > > myself
> > > > >> > > > some grief by getting called out automatically for
> > > CMakeLists.txt
> > > > >> > stuff,
> > > > >> > > > for example), but I respectfully decline for the following
> > > > >> reason(s):
> > > > >> > > >
> > > > >> > > > I feel that defining code-owners has some negative effects.
> > > > >> > > >
> > > > >> > > > Other committers may be reluctant to start reviewing and
> > > approving
> > > > >> PRs
> > > > >> > > > since they aren't the one listed, so I feel this will in the
> > > > >> long-run
> > > > >> > > > reduce the number of people doing code reviews.
> > > > >> > > >
> > > > >> > > > If there aren't enough people doing PR's, then people can
> > > complain
> > > > >> on
> > > > >> > > dev@
> > > > >> > > > asking for review.
> > > > >> > > >
> > > > >> > > > -Chris
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> > haibin@apache.org
> > > >
> > > > >> > wrote:
> > > > >> > > >
> > > > >> > > > > +1 (binding)
> > > > >> > > > >
> > > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > > > >> kellen.sunderland@gmail.com>
> > > > >> > > > > wrote:
> > > > >> > > > > > +1 (non-binding)
> > > > >> > > > > >
> > > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > > > >> steffenrochel@gmail.com
> > > > >> > >
> > > > >> > > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > I propose to adopt the proposal.
> > > > >> > > > > > > +1 (non-binding)
> > > > >> > > > > > >
> > > > >> > > > > > > Steffen
> > > > >> > > > > > >
> > > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> > muli.cmu@gmail.com
> > > >
> > > > >> > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > Hi Isabel,
> > > > >> > > > > > > >
> > > > >> > > > > > > > My apologies that not saying that clearly.
> > > > >> > > > > > > >
> > > > >> > > > > > > > The purpose of this proposal is encouraging more
> > > > >> contributors
> > > > >> > to
> > > > >> > > > help
> > > > >> > > > > > > > review and merge PRs. And also hope to shorten the
> > time
> > > > for
> > > > >> a
> > > > >> > PR
> > > > >> > > to
> > > > >> > > > > be
> > > > >> > > > > > > > merged. After assigning maintainers to modules, then
> > PR
> > > > >> > > > contributors
> > > > >> > > > > can
> > > > >> > > > > > > > easily contact the reviewers. In other words, github
> > > will
> > > > >> > > > > automatically
> > > > >> > > > > > > > assign the PR to the maintainer and send a
> > notification
> > > > >> email.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I don't think I put the term "inbox" in my
> proposal. I
> > > > never
> > > > >> > > > > discussed
> > > > >> > > > > > > PRs
> > > > >> > > > > > > > with other contributors by sending email directly,
> > which
> > > > is
> > > > >> > less
> > > > >> > > > > > > effective
> > > > >> > > > > > > > than just using github. I also don't aware any other
> > > > >> > contributor
> > > > >> > > > use
> > > > >> > > > > the
> > > > >> > > > > > > > direct email way. So I didn't clarify it on the
> > > proposal.
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm
> <
> > > > >> > > > > isabel@apache.org>
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > > > >> > > muli.cmu@gmail.com
> > > > >> > > > >:
> > > > >> > > > > > > > > >We should encourage to contract a specific
> > > contributor
> > > > >> for
> > > > >> > > > issues
> > > > >> > > > > and
> > > > >> > > > > > > > > >PRs.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > My head translates "encourage to contact specific
> > > > >> > contributor"
> > > > >> > > > into
> > > > >> > > > > > > > > "encourage to contact specific contributors
> inbox".
> > > This
> > > > >> > > > translated
> > > > >> > > > > > > > version
> > > > >> > > > > > > > > is what I would highly discourage.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > See the disclaimer here for reasons behind that:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Isabel
> > > > >> > > > > > > > > --
> > > > >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit
> > K-9
> > > > >> Mail
> > > > >> > > > > gesendet.
> > > > >> > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Sandeep Krishnamurthy
>
Re: Module maintainers proposal
Posted by sandeep krishnamurthy <sa...@gmail.com>.
+1 (binding) for suggestion around framing CODEOWNERS functionality as the
watchlist.
I also feel that we should enable and find/request more than 1 person per
module to help the project.
But, still, if it is something like +1 or watch button for modules rather
than a new PR to follow a topic, it would have been great. Something for
future :-)
Regards,
Sandeep
On Sun, Jan 14, 2018 at 4:18 PM, Steffen Rochel <st...@gmail.com>
wrote:
> Thanks Chris for the great reading suggestion
> <http://www.unterstein.net/su/docs/CathBaz.pdf>!
>
> I'm suggesting that we adopt Mu's proposal to use github code owner
> mechanism to identify designated maintainer for each package.
> To address the concerns raised in this thread I proposed
> to add into the header of the CODEOWNERS file
> https://github.com/apache/incubator-mxnet/pull/9426
> (changes below).
>
> Chris, Sebastian, Isabel - please suggest changes, but I hope I addressed
> your concerns.
>
> In the future we can also enable required reviews (see
> https://help.github.com/articles/about-pull-request-reviews/), but I would
> suggest to make one change at a time.
>
> I do suggest we should explore how we can best adopt existing github
> features before considering building additional CI tasks.
>
> Steffen
>
> # Please see documentation of use of CODEOWNERS file at
> # https://help.github.com/articles/about-codeowners/ and
> # https://github.com/blog/2392-introducing-code-owners
> #
> # The first owner listed for a package is considered the maintainer for a
> package.
> # Anybody can add themselves or a team (see
> https://help.github.com/articles/about-teams/)
> # as additional owners to get notified about changes in a specific package.
> #
> # By default the package maintainer should merge PR after appropriate
> review.
> # A PR which received 2 +1 (or LGTM) comments can be merged by any
> committer.
> # In the future we might consider adopting required reviews
> # (see https://help.github.com/articles/about-pull-request-reviews/)
>
>
> On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <bh...@gmail.com>
> wrote:
>
> > During the MXNet 1.0 release, there was feedback from the mentors and
> folks
> > in general@ to clarify at the top of the CODEOWNERs file on what the
> > contents of this file meant.
> >
> > Hi Mu,
> >
> > Please add the description of the file in the file header. I expect that
> > this will be a requirement for the next MXNet release 1.0.1.
> >
> > Thanks,
> > Bhavin Thaker.
> >
> > On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <cj...@gmail.com>
> > wrote:
> >
> > > i’d be +1 if CODEOWNERS file has a big note at the top saying basically
> > > it’s just for watching code changes that you’d like to know about (to
> > > review or just to follow) and that anyone can add themself.
> > >
> > > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <cj...@gmail.com>
> > > wrote:
> > >
> > > > Does it have to be called "CODEOWNERS"? I would be more comfortable
> > with
> > > > it if it's a "watch list" where it just means you wish to watch code
> > here
> > > > or there in the source structure and anyone can add or remove their
> > name
> > > > from watching some part of the code at any time.
> > > >
> > > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > > > marco.g.abreu@googlemail.com> wrote:
> > > >
> > > >> I agree. How about we find another way to allow people to subscribe
> > for
> > > >> changes in a specific file or directory?
> > > >>
> > > >> -Marco
> > > >>
> > > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > > cjolivier01@gmail.com
> > > >> >:
> > > >>
> > > >> > Have you read "The Cathedral and the Bazaar"?
> > > >> >
> > > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > > >> >
> > > >> > One of the points I took from this is that once a project finds
> its
> > > >> stride,
> > > >> > it actually runs more efficiently without centralization than
> with.
> > > >> >
> > > >> > -Chris
> > > >> >
> > > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > > >> > marco.g.abreu@googlemail.com> wrote:
> > > >> >
> > > >> > > Hi Chris,
> > > >> > >
> > > >> > > you have a good point about people being afraid of reviewing PRs
> > > which
> > > >> > they
> > > >> > > are not assigned to and I totally agree that we should encourage
> > > >> > everybody
> > > >> > > to review PRs.
> > > >> > >
> > > >> > > One important advantage I see in this is the notification: since
> > we
> > > >> are
> > > >> > not
> > > >> > > using the feature to required an approval, this step is entirely
> > for
> > > >> > > information purpose. I, for example, would like to get notified
> > if a
> > > >> PR
> > > >> > to
> > > >> > > change a CI file would be created. Just as an example: over
> > > >> Christmas, a
> > > >> > PR
> > > >> > > to update mkl has been pushed without me knowing about it.
> > Somehow,
> > > >> after
> > > >> > > my vacation, we started to get issues with mkl test - I only
> found
> > > out
> > > >> > > about this PR after quite a long investigation. If we would
> extend
> > > the
> > > >> > > usage of the code maintainers, we'll make sure that changes like
> > > these
> > > >> > will
> > > >> > > notify the people who have the best knowledge about that part.
> > > >> > >
> > > >> > > Marco
> > > >> > >
> > > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > > >> cjolivier01@gmail.com
> > > >> > >:
> > > >> > >
> > > >> > > > -1 (binding)
> > > >> > > >
> > > >> > > > I totally understand the motivation for this (I've definitely
> > > saved
> > > >> > > myself
> > > >> > > > some grief by getting called out automatically for
> > CMakeLists.txt
> > > >> > stuff,
> > > >> > > > for example), but I respectfully decline for the following
> > > >> reason(s):
> > > >> > > >
> > > >> > > > I feel that defining code-owners has some negative effects.
> > > >> > > >
> > > >> > > > Other committers may be reluctant to start reviewing and
> > approving
> > > >> PRs
> > > >> > > > since they aren't the one listed, so I feel this will in the
> > > >> long-run
> > > >> > > > reduce the number of people doing code reviews.
> > > >> > > >
> > > >> > > > If there aren't enough people doing PR's, then people can
> > complain
> > > >> on
> > > >> > > dev@
> > > >> > > > asking for review.
> > > >> > > >
> > > >> > > > -Chris
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <
> haibin@apache.org
> > >
> > > >> > wrote:
> > > >> > > >
> > > >> > > > > +1 (binding)
> > > >> > > > >
> > > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > > >> kellen.sunderland@gmail.com>
> > > >> > > > > wrote:
> > > >> > > > > > +1 (non-binding)
> > > >> > > > > >
> > > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > > >> steffenrochel@gmail.com
> > > >> > >
> > > >> > > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > I propose to adopt the proposal.
> > > >> > > > > > > +1 (non-binding)
> > > >> > > > > > >
> > > >> > > > > > > Steffen
> > > >> > > > > > >
> > > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <
> muli.cmu@gmail.com
> > >
> > > >> > wrote:
> > > >> > > > > > >
> > > >> > > > > > > > Hi Isabel,
> > > >> > > > > > > >
> > > >> > > > > > > > My apologies that not saying that clearly.
> > > >> > > > > > > >
> > > >> > > > > > > > The purpose of this proposal is encouraging more
> > > >> contributors
> > > >> > to
> > > >> > > > help
> > > >> > > > > > > > review and merge PRs. And also hope to shorten the
> time
> > > for
> > > >> a
> > > >> > PR
> > > >> > > to
> > > >> > > > > be
> > > >> > > > > > > > merged. After assigning maintainers to modules, then
> PR
> > > >> > > > contributors
> > > >> > > > > can
> > > >> > > > > > > > easily contact the reviewers. In other words, github
> > will
> > > >> > > > > automatically
> > > >> > > > > > > > assign the PR to the maintainer and send a
> notification
> > > >> email.
> > > >> > > > > > > >
> > > >> > > > > > > > I don't think I put the term "inbox" in my proposal. I
> > > never
> > > >> > > > > discussed
> > > >> > > > > > > PRs
> > > >> > > > > > > > with other contributors by sending email directly,
> which
> > > is
> > > >> > less
> > > >> > > > > > > effective
> > > >> > > > > > > > than just using github. I also don't aware any other
> > > >> > contributor
> > > >> > > > use
> > > >> > > > > the
> > > >> > > > > > > > direct email way. So I didn't clarify it on the
> > proposal.
> > > >> > > > > > > >
> > > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > > >> > > > > isabel@apache.org>
> > > >> > > > > > > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > > >> > > muli.cmu@gmail.com
> > > >> > > > >:
> > > >> > > > > > > > > >We should encourage to contract a specific
> > contributor
> > > >> for
> > > >> > > > issues
> > > >> > > > > and
> > > >> > > > > > > > > >PRs.
> > > >> > > > > > > > >
> > > >> > > > > > > > > My head translates "encourage to contact specific
> > > >> > contributor"
> > > >> > > > into
> > > >> > > > > > > > > "encourage to contact specific contributors inbox".
> > This
> > > >> > > > translated
> > > >> > > > > > > > version
> > > >> > > > > > > > > is what I would highly discourage.
> > > >> > > > > > > > >
> > > >> > > > > > > > > See the disclaimer here for reasons behind that:
> > > >> > > > > > > > >
> > > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > > Isabel
> > > >> > > > > > > > > --
> > > >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit
> K-9
> > > >> Mail
> > > >> > > > > gesendet.
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
--
Sandeep Krishnamurthy
Re: Module maintainers proposal
Posted by Steffen Rochel <st...@gmail.com>.
Thanks Chris for the great reading suggestion
<http://www.unterstein.net/su/docs/CathBaz.pdf>!
I'm suggesting that we adopt Mu's proposal to use github code owner
mechanism to identify designated maintainer for each package.
To address the concerns raised in this thread I proposed
to add into the header of the CODEOWNERS file
https://github.com/apache/incubator-mxnet/pull/9426
(changes below).
Chris, Sebastian, Isabel - please suggest changes, but I hope I addressed
your concerns.
In the future we can also enable required reviews (see
https://help.github.com/articles/about-pull-request-reviews/), but I would
suggest to make one change at a time.
I do suggest we should explore how we can best adopt existing github
features before considering building additional CI tasks.
Steffen
# Please see documentation of use of CODEOWNERS file at
# https://help.github.com/articles/about-codeowners/ and
# https://github.com/blog/2392-introducing-code-owners
#
# The first owner listed for a package is considered the maintainer for a
package.
# Anybody can add themselves or a team (see
https://help.github.com/articles/about-teams/)
# as additional owners to get notified about changes in a specific package.
#
# By default the package maintainer should merge PR after appropriate
review.
# A PR which received 2 +1 (or LGTM) comments can be merged by any
committer.
# In the future we might consider adopting required reviews
# (see https://help.github.com/articles/about-pull-request-reviews/)
On Fri, Jan 12, 2018 at 7:22 PM Bhavin Thaker <bh...@gmail.com>
wrote:
> During the MXNet 1.0 release, there was feedback from the mentors and folks
> in general@ to clarify at the top of the CODEOWNERs file on what the
> contents of this file meant.
>
> Hi Mu,
>
> Please add the description of the file in the file header. I expect that
> this will be a requirement for the next MXNet release 1.0.1.
>
> Thanks,
> Bhavin Thaker.
>
> On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <cj...@gmail.com>
> wrote:
>
> > i’d be +1 if CODEOWNERS file has a big note at the top saying basically
> > it’s just for watching code changes that you’d like to know about (to
> > review or just to follow) and that anyone can add themself.
> >
> > On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <cj...@gmail.com>
> > wrote:
> >
> > > Does it have to be called "CODEOWNERS"? I would be more comfortable
> with
> > > it if it's a "watch list" where it just means you wish to watch code
> here
> > > or there in the source structure and anyone can add or remove their
> name
> > > from watching some part of the code at any time.
> > >
> > > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > > marco.g.abreu@googlemail.com> wrote:
> > >
> > >> I agree. How about we find another way to allow people to subscribe
> for
> > >> changes in a specific file or directory?
> > >>
> > >> -Marco
> > >>
> > >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> > cjolivier01@gmail.com
> > >> >:
> > >>
> > >> > Have you read "The Cathedral and the Bazaar"?
> > >> >
> > >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> > >> >
> > >> > One of the points I took from this is that once a project finds its
> > >> stride,
> > >> > it actually runs more efficiently without centralization than with.
> > >> >
> > >> > -Chris
> > >> >
> > >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > >> > marco.g.abreu@googlemail.com> wrote:
> > >> >
> > >> > > Hi Chris,
> > >> > >
> > >> > > you have a good point about people being afraid of reviewing PRs
> > which
> > >> > they
> > >> > > are not assigned to and I totally agree that we should encourage
> > >> > everybody
> > >> > > to review PRs.
> > >> > >
> > >> > > One important advantage I see in this is the notification: since
> we
> > >> are
> > >> > not
> > >> > > using the feature to required an approval, this step is entirely
> for
> > >> > > information purpose. I, for example, would like to get notified
> if a
> > >> PR
> > >> > to
> > >> > > change a CI file would be created. Just as an example: over
> > >> Christmas, a
> > >> > PR
> > >> > > to update mkl has been pushed without me knowing about it.
> Somehow,
> > >> after
> > >> > > my vacation, we started to get issues with mkl test - I only found
> > out
> > >> > > about this PR after quite a long investigation. If we would extend
> > the
> > >> > > usage of the code maintainers, we'll make sure that changes like
> > these
> > >> > will
> > >> > > notify the people who have the best knowledge about that part.
> > >> > >
> > >> > > Marco
> > >> > >
> > >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > >> cjolivier01@gmail.com
> > >> > >:
> > >> > >
> > >> > > > -1 (binding)
> > >> > > >
> > >> > > > I totally understand the motivation for this (I've definitely
> > saved
> > >> > > myself
> > >> > > > some grief by getting called out automatically for
> CMakeLists.txt
> > >> > stuff,
> > >> > > > for example), but I respectfully decline for the following
> > >> reason(s):
> > >> > > >
> > >> > > > I feel that defining code-owners has some negative effects.
> > >> > > >
> > >> > > > Other committers may be reluctant to start reviewing and
> approving
> > >> PRs
> > >> > > > since they aren't the one listed, so I feel this will in the
> > >> long-run
> > >> > > > reduce the number of people doing code reviews.
> > >> > > >
> > >> > > > If there aren't enough people doing PR's, then people can
> complain
> > >> on
> > >> > > dev@
> > >> > > > asking for review.
> > >> > > >
> > >> > > > -Chris
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <haibin@apache.org
> >
> > >> > wrote:
> > >> > > >
> > >> > > > > +1 (binding)
> > >> > > > >
> > >> > > > > On 2018-01-12 10:10, kellen sunderland <
> > >> kellen.sunderland@gmail.com>
> > >> > > > > wrote:
> > >> > > > > > +1 (non-binding)
> > >> > > > > >
> > >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > >> steffenrochel@gmail.com
> > >> > >
> > >> > > > > wrote:
> > >> > > > > >
> > >> > > > > > > I propose to adopt the proposal.
> > >> > > > > > > +1 (non-binding)
> > >> > > > > > >
> > >> > > > > > > Steffen
> > >> > > > > > >
> > >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <muli.cmu@gmail.com
> >
> > >> > wrote:
> > >> > > > > > >
> > >> > > > > > > > Hi Isabel,
> > >> > > > > > > >
> > >> > > > > > > > My apologies that not saying that clearly.
> > >> > > > > > > >
> > >> > > > > > > > The purpose of this proposal is encouraging more
> > >> contributors
> > >> > to
> > >> > > > help
> > >> > > > > > > > review and merge PRs. And also hope to shorten the time
> > for
> > >> a
> > >> > PR
> > >> > > to
> > >> > > > > be
> > >> > > > > > > > merged. After assigning maintainers to modules, then PR
> > >> > > > contributors
> > >> > > > > can
> > >> > > > > > > > easily contact the reviewers. In other words, github
> will
> > >> > > > > automatically
> > >> > > > > > > > assign the PR to the maintainer and send a notification
> > >> email.
> > >> > > > > > > >
> > >> > > > > > > > I don't think I put the term "inbox" in my proposal. I
> > never
> > >> > > > > discussed
> > >> > > > > > > PRs
> > >> > > > > > > > with other contributors by sending email directly, which
> > is
> > >> > less
> > >> > > > > > > effective
> > >> > > > > > > > than just using github. I also don't aware any other
> > >> > contributor
> > >> > > > use
> > >> > > > > the
> > >> > > > > > > > direct email way. So I didn't clarify it on the
> proposal.
> > >> > > > > > > >
> > >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > >> > > > > isabel@apache.org>
> > >> > > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > >> > > muli.cmu@gmail.com
> > >> > > > >:
> > >> > > > > > > > > >We should encourage to contract a specific
> contributor
> > >> for
> > >> > > > issues
> > >> > > > > and
> > >> > > > > > > > > >PRs.
> > >> > > > > > > > >
> > >> > > > > > > > > My head translates "encourage to contact specific
> > >> > contributor"
> > >> > > > into
> > >> > > > > > > > > "encourage to contact specific contributors inbox".
> This
> > >> > > > translated
> > >> > > > > > > > version
> > >> > > > > > > > > is what I would highly discourage.
> > >> > > > > > > > >
> > >> > > > > > > > > See the disclaimer here for reasons behind that:
> > >> > > > > > > > >
> > >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > Isabel
> > >> > > > > > > > > --
> > >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9
> > >> Mail
> > >> > > > > gesendet.
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Bhavin Thaker <bh...@gmail.com>.
During the MXNet 1.0 release, there was feedback from the mentors and folks
in general@ to clarify at the top of the CODEOWNERs file on what the
contents of this file meant.
Hi Mu,
Please add the description of the file in the file header. I expect that
this will be a requirement for the next MXNet release 1.0.1.
Thanks,
Bhavin Thaker.
On Fri, Jan 12, 2018 at 5:43 PM Chris Olivier <cj...@gmail.com> wrote:
> i’d be +1 if CODEOWNERS file has a big note at the top saying basically
> it’s just for watching code changes that you’d like to know about (to
> review or just to follow) and that anyone can add themself.
>
> On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <cj...@gmail.com>
> wrote:
>
> > Does it have to be called "CODEOWNERS"? I would be more comfortable with
> > it if it's a "watch list" where it just means you wish to watch code here
> > or there in the source structure and anyone can add or remove their name
> > from watching some part of the code at any time.
> >
> > On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> > marco.g.abreu@googlemail.com> wrote:
> >
> >> I agree. How about we find another way to allow people to subscribe for
> >> changes in a specific file or directory?
> >>
> >> -Marco
> >>
> >> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <
> cjolivier01@gmail.com
> >> >:
> >>
> >> > Have you read "The Cathedral and the Bazaar"?
> >> >
> >> > http://www.unterstein.net/su/docs/CathBaz.pdf
> >> >
> >> > One of the points I took from this is that once a project finds its
> >> stride,
> >> > it actually runs more efficiently without centralization than with.
> >> >
> >> > -Chris
> >> >
> >> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> >> > marco.g.abreu@googlemail.com> wrote:
> >> >
> >> > > Hi Chris,
> >> > >
> >> > > you have a good point about people being afraid of reviewing PRs
> which
> >> > they
> >> > > are not assigned to and I totally agree that we should encourage
> >> > everybody
> >> > > to review PRs.
> >> > >
> >> > > One important advantage I see in this is the notification: since we
> >> are
> >> > not
> >> > > using the feature to required an approval, this step is entirely for
> >> > > information purpose. I, for example, would like to get notified if a
> >> PR
> >> > to
> >> > > change a CI file would be created. Just as an example: over
> >> Christmas, a
> >> > PR
> >> > > to update mkl has been pushed without me knowing about it. Somehow,
> >> after
> >> > > my vacation, we started to get issues with mkl test - I only found
> out
> >> > > about this PR after quite a long investigation. If we would extend
> the
> >> > > usage of the code maintainers, we'll make sure that changes like
> these
> >> > will
> >> > > notify the people who have the best knowledge about that part.
> >> > >
> >> > > Marco
> >> > >
> >> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> >> cjolivier01@gmail.com
> >> > >:
> >> > >
> >> > > > -1 (binding)
> >> > > >
> >> > > > I totally understand the motivation for this (I've definitely
> saved
> >> > > myself
> >> > > > some grief by getting called out automatically for CMakeLists.txt
> >> > stuff,
> >> > > > for example), but I respectfully decline for the following
> >> reason(s):
> >> > > >
> >> > > > I feel that defining code-owners has some negative effects.
> >> > > >
> >> > > > Other committers may be reluctant to start reviewing and approving
> >> PRs
> >> > > > since they aren't the one listed, so I feel this will in the
> >> long-run
> >> > > > reduce the number of people doing code reviews.
> >> > > >
> >> > > > If there aren't enough people doing PR's, then people can complain
> >> on
> >> > > dev@
> >> > > > asking for review.
> >> > > >
> >> > > > -Chris
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org>
> >> > wrote:
> >> > > >
> >> > > > > +1 (binding)
> >> > > > >
> >> > > > > On 2018-01-12 10:10, kellen sunderland <
> >> kellen.sunderland@gmail.com>
> >> > > > > wrote:
> >> > > > > > +1 (non-binding)
> >> > > > > >
> >> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> >> steffenrochel@gmail.com
> >> > >
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > > I propose to adopt the proposal.
> >> > > > > > > +1 (non-binding)
> >> > > > > > >
> >> > > > > > > Steffen
> >> > > > > > >
> >> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com>
> >> > wrote:
> >> > > > > > >
> >> > > > > > > > Hi Isabel,
> >> > > > > > > >
> >> > > > > > > > My apologies that not saying that clearly.
> >> > > > > > > >
> >> > > > > > > > The purpose of this proposal is encouraging more
> >> contributors
> >> > to
> >> > > > help
> >> > > > > > > > review and merge PRs. And also hope to shorten the time
> for
> >> a
> >> > PR
> >> > > to
> >> > > > > be
> >> > > > > > > > merged. After assigning maintainers to modules, then PR
> >> > > > contributors
> >> > > > > can
> >> > > > > > > > easily contact the reviewers. In other words, github will
> >> > > > > automatically
> >> > > > > > > > assign the PR to the maintainer and send a notification
> >> email.
> >> > > > > > > >
> >> > > > > > > > I don't think I put the term "inbox" in my proposal. I
> never
> >> > > > > discussed
> >> > > > > > > PRs
> >> > > > > > > > with other contributors by sending email directly, which
> is
> >> > less
> >> > > > > > > effective
> >> > > > > > > > than just using github. I also don't aware any other
> >> > contributor
> >> > > > use
> >> > > > > the
> >> > > > > > > > direct email way. So I didn't clarify it on the proposal.
> >> > > > > > > >
> >> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> >> > > > > isabel@apache.org>
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> >> > > muli.cmu@gmail.com
> >> > > > >:
> >> > > > > > > > > >We should encourage to contract a specific contributor
> >> for
> >> > > > issues
> >> > > > > and
> >> > > > > > > > > >PRs.
> >> > > > > > > > >
> >> > > > > > > > > My head translates "encourage to contact specific
> >> > contributor"
> >> > > > into
> >> > > > > > > > > "encourage to contact specific contributors inbox". This
> >> > > > translated
> >> > > > > > > > version
> >> > > > > > > > > is what I would highly discourage.
> >> > > > > > > > >
> >> > > > > > > > > See the disclaimer here for reasons behind that:
> >> > > > > > > > >
> >> > > > > > > > > https://home.apache.org/~hossman/#private_q
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > Isabel
> >> > > > > > > > > --
> >> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9
> >> Mail
> >> > > > > gesendet.
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
i’d be +1 if CODEOWNERS file has a big note at the top saying basically
it’s just for watching code changes that you’d like to know about (to
review or just to follow) and that anyone can add themself.
On Fri, Jan 12, 2018 at 1:58 PM Chris Olivier <cj...@gmail.com> wrote:
> Does it have to be called "CODEOWNERS"? I would be more comfortable with
> it if it's a "watch list" where it just means you wish to watch code here
> or there in the source structure and anyone can add or remove their name
> from watching some part of the code at any time.
>
> On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> marco.g.abreu@googlemail.com> wrote:
>
>> I agree. How about we find another way to allow people to subscribe for
>> changes in a specific file or directory?
>>
>> -Marco
>>
>> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <cjolivier01@gmail.com
>> >:
>>
>> > Have you read "The Cathedral and the Bazaar"?
>> >
>> > http://www.unterstein.net/su/docs/CathBaz.pdf
>> >
>> > One of the points I took from this is that once a project finds its
>> stride,
>> > it actually runs more efficiently without centralization than with.
>> >
>> > -Chris
>> >
>> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
>> > marco.g.abreu@googlemail.com> wrote:
>> >
>> > > Hi Chris,
>> > >
>> > > you have a good point about people being afraid of reviewing PRs which
>> > they
>> > > are not assigned to and I totally agree that we should encourage
>> > everybody
>> > > to review PRs.
>> > >
>> > > One important advantage I see in this is the notification: since we
>> are
>> > not
>> > > using the feature to required an approval, this step is entirely for
>> > > information purpose. I, for example, would like to get notified if a
>> PR
>> > to
>> > > change a CI file would be created. Just as an example: over
>> Christmas, a
>> > PR
>> > > to update mkl has been pushed without me knowing about it. Somehow,
>> after
>> > > my vacation, we started to get issues with mkl test - I only found out
>> > > about this PR after quite a long investigation. If we would extend the
>> > > usage of the code maintainers, we'll make sure that changes like these
>> > will
>> > > notify the people who have the best knowledge about that part.
>> > >
>> > > Marco
>> > >
>> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
>> cjolivier01@gmail.com
>> > >:
>> > >
>> > > > -1 (binding)
>> > > >
>> > > > I totally understand the motivation for this (I've definitely saved
>> > > myself
>> > > > some grief by getting called out automatically for CMakeLists.txt
>> > stuff,
>> > > > for example), but I respectfully decline for the following
>> reason(s):
>> > > >
>> > > > I feel that defining code-owners has some negative effects.
>> > > >
>> > > > Other committers may be reluctant to start reviewing and approving
>> PRs
>> > > > since they aren't the one listed, so I feel this will in the
>> long-run
>> > > > reduce the number of people doing code reviews.
>> > > >
>> > > > If there aren't enough people doing PR's, then people can complain
>> on
>> > > dev@
>> > > > asking for review.
>> > > >
>> > > > -Chris
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org>
>> > wrote:
>> > > >
>> > > > > +1 (binding)
>> > > > >
>> > > > > On 2018-01-12 10:10, kellen sunderland <
>> kellen.sunderland@gmail.com>
>> > > > > wrote:
>> > > > > > +1 (non-binding)
>> > > > > >
>> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
>> steffenrochel@gmail.com
>> > >
>> > > > > wrote:
>> > > > > >
>> > > > > > > I propose to adopt the proposal.
>> > > > > > > +1 (non-binding)
>> > > > > > >
>> > > > > > > Steffen
>> > > > > > >
>> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com>
>> > wrote:
>> > > > > > >
>> > > > > > > > Hi Isabel,
>> > > > > > > >
>> > > > > > > > My apologies that not saying that clearly.
>> > > > > > > >
>> > > > > > > > The purpose of this proposal is encouraging more
>> contributors
>> > to
>> > > > help
>> > > > > > > > review and merge PRs. And also hope to shorten the time for
>> a
>> > PR
>> > > to
>> > > > > be
>> > > > > > > > merged. After assigning maintainers to modules, then PR
>> > > > contributors
>> > > > > can
>> > > > > > > > easily contact the reviewers. In other words, github will
>> > > > > automatically
>> > > > > > > > assign the PR to the maintainer and send a notification
>> email.
>> > > > > > > >
>> > > > > > > > I don't think I put the term "inbox" in my proposal. I never
>> > > > > discussed
>> > > > > > > PRs
>> > > > > > > > with other contributors by sending email directly, which is
>> > less
>> > > > > > > effective
>> > > > > > > > than just using github. I also don't aware any other
>> > contributor
>> > > > use
>> > > > > the
>> > > > > > > > direct email way. So I didn't clarify it on the proposal.
>> > > > > > > >
>> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
>> > > > > isabel@apache.org>
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
>> > > muli.cmu@gmail.com
>> > > > >:
>> > > > > > > > > >We should encourage to contract a specific contributor
>> for
>> > > > issues
>> > > > > and
>> > > > > > > > > >PRs.
>> > > > > > > > >
>> > > > > > > > > My head translates "encourage to contact specific
>> > contributor"
>> > > > into
>> > > > > > > > > "encourage to contact specific contributors inbox". This
>> > > > translated
>> > > > > > > > version
>> > > > > > > > > is what I would highly discourage.
>> > > > > > > > >
>> > > > > > > > > See the disclaimer here for reasons behind that:
>> > > > > > > > >
>> > > > > > > > > https://home.apache.org/~hossman/#private_q
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Isabel
>> > > > > > > > > --
>> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9
>> Mail
>> > > > > gesendet.
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Module maintainers proposal
Posted by Marco de Abreu <ma...@googlemail.com>.
Unfortunately, yes. This is hardcoded by GitHub:
https://help.github.com/articles/about-codeowners/
Also, only committers can be selected as "code owners". Contributors will
not be notified. What does everybody think about replacing the CODEOWNERS
file with a proper task (maybe on CI) or service which handles this
notifiying properly in the long term?
-Marco
On Fri, Jan 12, 2018 at 10:58 PM, Chris Olivier <cj...@gmail.com>
wrote:
> Does it have to be called "CODEOWNERS"? I would be more comfortable with it
> if it's a "watch list" where it just means you wish to watch code here or
> there in the source structure and anyone can add or remove their name from
> watching some part of the code at any time.
>
> On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
> marco.g.abreu@googlemail.com> wrote:
>
> > I agree. How about we find another way to allow people to subscribe for
> > changes in a specific file or directory?
> >
> > -Marco
> >
> > Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <cjolivier01@gmail.com
> >:
> >
> > > Have you read "The Cathedral and the Bazaar"?
> > >
> > > http://www.unterstein.net/su/docs/CathBaz.pdf
> > >
> > > One of the points I took from this is that once a project finds its
> > stride,
> > > it actually runs more efficiently without centralization than with.
> > >
> > > -Chris
> > >
> > > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > > marco.g.abreu@googlemail.com> wrote:
> > >
> > > > Hi Chris,
> > > >
> > > > you have a good point about people being afraid of reviewing PRs
> which
> > > they
> > > > are not assigned to and I totally agree that we should encourage
> > > everybody
> > > > to review PRs.
> > > >
> > > > One important advantage I see in this is the notification: since we
> are
> > > not
> > > > using the feature to required an approval, this step is entirely for
> > > > information purpose. I, for example, would like to get notified if a
> PR
> > > to
> > > > change a CI file would be created. Just as an example: over
> Christmas,
> > a
> > > PR
> > > > to update mkl has been pushed without me knowing about it. Somehow,
> > after
> > > > my vacation, we started to get issues with mkl test - I only found
> out
> > > > about this PR after quite a long investigation. If we would extend
> the
> > > > usage of the code maintainers, we'll make sure that changes like
> these
> > > will
> > > > notify the people who have the best knowledge about that part.
> > > >
> > > > Marco
> > > >
> > > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> > cjolivier01@gmail.com
> > > >:
> > > >
> > > > > -1 (binding)
> > > > >
> > > > > I totally understand the motivation for this (I've definitely saved
> > > > myself
> > > > > some grief by getting called out automatically for CMakeLists.txt
> > > stuff,
> > > > > for example), but I respectfully decline for the following
> reason(s):
> > > > >
> > > > > I feel that defining code-owners has some negative effects.
> > > > >
> > > > > Other committers may be reluctant to start reviewing and approving
> > PRs
> > > > > since they aren't the one listed, so I feel this will in the
> long-run
> > > > > reduce the number of people doing code reviews.
> > > > >
> > > > > If there aren't enough people doing PR's, then people can complain
> on
> > > > dev@
> > > > > asking for review.
> > > > >
> > > > > -Chris
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org>
> > > wrote:
> > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > On 2018-01-12 10:10, kellen sunderland <
> > kellen.sunderland@gmail.com>
> > > > > > wrote:
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> > steffenrochel@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > I propose to adopt the proposal.
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Steffen
> > > > > > > >
> > > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com>
> > > wrote:
> > > > > > > >
> > > > > > > > > Hi Isabel,
> > > > > > > > >
> > > > > > > > > My apologies that not saying that clearly.
> > > > > > > > >
> > > > > > > > > The purpose of this proposal is encouraging more
> contributors
> > > to
> > > > > help
> > > > > > > > > review and merge PRs. And also hope to shorten the time
> for a
> > > PR
> > > > to
> > > > > > be
> > > > > > > > > merged. After assigning maintainers to modules, then PR
> > > > > contributors
> > > > > > can
> > > > > > > > > easily contact the reviewers. In other words, github will
> > > > > > automatically
> > > > > > > > > assign the PR to the maintainer and send a notification
> > email.
> > > > > > > > >
> > > > > > > > > I don't think I put the term "inbox" in my proposal. I
> never
> > > > > > discussed
> > > > > > > > PRs
> > > > > > > > > with other contributors by sending email directly, which is
> > > less
> > > > > > > > effective
> > > > > > > > > than just using github. I also don't aware any other
> > > contributor
> > > > > use
> > > > > > the
> > > > > > > > > direct email way. So I didn't clarify it on the proposal.
> > > > > > > > >
> > > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > > > > > isabel@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > > > muli.cmu@gmail.com
> > > > > >:
> > > > > > > > > > >We should encourage to contract a specific contributor
> for
> > > > > issues
> > > > > > and
> > > > > > > > > > >PRs.
> > > > > > > > > >
> > > > > > > > > > My head translates "encourage to contact specific
> > > contributor"
> > > > > into
> > > > > > > > > > "encourage to contact specific contributors inbox". This
> > > > > translated
> > > > > > > > > version
> > > > > > > > > > is what I would highly discourage.
> > > > > > > > > >
> > > > > > > > > > See the disclaimer here for reasons behind that:
> > > > > > > > > >
> > > > > > > > > > https://home.apache.org/~hossman/#private_q
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Isabel
> > > > > > > > > > --
> > > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9
> Mail
> > > > > > gesendet.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
Does it have to be called "CODEOWNERS"? I would be more comfortable with it
if it's a "watch list" where it just means you wish to watch code here or
there in the source structure and anyone can add or remove their name from
watching some part of the code at any time.
On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
marco.g.abreu@googlemail.com> wrote:
> I agree. How about we find another way to allow people to subscribe for
> changes in a specific file or directory?
>
> -Marco
>
> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <cj...@gmail.com>:
>
> > Have you read "The Cathedral and the Bazaar"?
> >
> > http://www.unterstein.net/su/docs/CathBaz.pdf
> >
> > One of the points I took from this is that once a project finds its
> stride,
> > it actually runs more efficiently without centralization than with.
> >
> > -Chris
> >
> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > marco.g.abreu@googlemail.com> wrote:
> >
> > > Hi Chris,
> > >
> > > you have a good point about people being afraid of reviewing PRs which
> > they
> > > are not assigned to and I totally agree that we should encourage
> > everybody
> > > to review PRs.
> > >
> > > One important advantage I see in this is the notification: since we are
> > not
> > > using the feature to required an approval, this step is entirely for
> > > information purpose. I, for example, would like to get notified if a PR
> > to
> > > change a CI file would be created. Just as an example: over Christmas,
> a
> > PR
> > > to update mkl has been pushed without me knowing about it. Somehow,
> after
> > > my vacation, we started to get issues with mkl test - I only found out
> > > about this PR after quite a long investigation. If we would extend the
> > > usage of the code maintainers, we'll make sure that changes like these
> > will
> > > notify the people who have the best knowledge about that part.
> > >
> > > Marco
> > >
> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> cjolivier01@gmail.com
> > >:
> > >
> > > > -1 (binding)
> > > >
> > > > I totally understand the motivation for this (I've definitely saved
> > > myself
> > > > some grief by getting called out automatically for CMakeLists.txt
> > stuff,
> > > > for example), but I respectfully decline for the following reason(s):
> > > >
> > > > I feel that defining code-owners has some negative effects.
> > > >
> > > > Other committers may be reluctant to start reviewing and approving
> PRs
> > > > since they aren't the one listed, so I feel this will in the long-run
> > > > reduce the number of people doing code reviews.
> > > >
> > > > If there aren't enough people doing PR's, then people can complain on
> > > dev@
> > > > asking for review.
> > > >
> > > > -Chris
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org>
> > wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > On 2018-01-12 10:10, kellen sunderland <
> kellen.sunderland@gmail.com>
> > > > > wrote:
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> steffenrochel@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > I propose to adopt the proposal.
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Steffen
> > > > > > >
> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com>
> > wrote:
> > > > > > >
> > > > > > > > Hi Isabel,
> > > > > > > >
> > > > > > > > My apologies that not saying that clearly.
> > > > > > > >
> > > > > > > > The purpose of this proposal is encouraging more contributors
> > to
> > > > help
> > > > > > > > review and merge PRs. And also hope to shorten the time for a
> > PR
> > > to
> > > > > be
> > > > > > > > merged. After assigning maintainers to modules, then PR
> > > > contributors
> > > > > can
> > > > > > > > easily contact the reviewers. In other words, github will
> > > > > automatically
> > > > > > > > assign the PR to the maintainer and send a notification
> email.
> > > > > > > >
> > > > > > > > I don't think I put the term "inbox" in my proposal. I never
> > > > > discussed
> > > > > > > PRs
> > > > > > > > with other contributors by sending email directly, which is
> > less
> > > > > > > effective
> > > > > > > > than just using github. I also don't aware any other
> > contributor
> > > > use
> > > > > the
> > > > > > > > direct email way. So I didn't clarify it on the proposal.
> > > > > > > >
> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > > > > isabel@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > > muli.cmu@gmail.com
> > > > >:
> > > > > > > > > >We should encourage to contract a specific contributor for
> > > > issues
> > > > > and
> > > > > > > > > >PRs.
> > > > > > > > >
> > > > > > > > > My head translates "encourage to contact specific
> > contributor"
> > > > into
> > > > > > > > > "encourage to contact specific contributors inbox". This
> > > > translated
> > > > > > > > version
> > > > > > > > > is what I would highly discourage.
> > > > > > > > >
> > > > > > > > > See the disclaimer here for reasons behind that:
> > > > > > > > >
> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Isabel
> > > > > > > > > --
> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> > > > > gesendet.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
On Amazon:
https://www.amazon.com/Cathedral-Bazaar-Musings-Accidental-Revolutionary-ebook/dp/B0026OR3LM
On Fri, Jan 12, 2018 at 11:52 AM, Marco de Abreu <
marco.g.abreu@googlemail.com> wrote:
> I agree. How about we find another way to allow people to subscribe for
> changes in a specific file or directory?
>
> -Marco
>
> Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <cj...@gmail.com>:
>
> > Have you read "The Cathedral and the Bazaar"?
> >
> > http://www.unterstein.net/su/docs/CathBaz.pdf
> >
> > One of the points I took from this is that once a project finds its
> stride,
> > it actually runs more efficiently without centralization than with.
> >
> > -Chris
> >
> > On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> > marco.g.abreu@googlemail.com> wrote:
> >
> > > Hi Chris,
> > >
> > > you have a good point about people being afraid of reviewing PRs which
> > they
> > > are not assigned to and I totally agree that we should encourage
> > everybody
> > > to review PRs.
> > >
> > > One important advantage I see in this is the notification: since we are
> > not
> > > using the feature to required an approval, this step is entirely for
> > > information purpose. I, for example, would like to get notified if a PR
> > to
> > > change a CI file would be created. Just as an example: over Christmas,
> a
> > PR
> > > to update mkl has been pushed without me knowing about it. Somehow,
> after
> > > my vacation, we started to get issues with mkl test - I only found out
> > > about this PR after quite a long investigation. If we would extend the
> > > usage of the code maintainers, we'll make sure that changes like these
> > will
> > > notify the people who have the best knowledge about that part.
> > >
> > > Marco
> > >
> > > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <
> cjolivier01@gmail.com
> > >:
> > >
> > > > -1 (binding)
> > > >
> > > > I totally understand the motivation for this (I've definitely saved
> > > myself
> > > > some grief by getting called out automatically for CMakeLists.txt
> > stuff,
> > > > for example), but I respectfully decline for the following reason(s):
> > > >
> > > > I feel that defining code-owners has some negative effects.
> > > >
> > > > Other committers may be reluctant to start reviewing and approving
> PRs
> > > > since they aren't the one listed, so I feel this will in the long-run
> > > > reduce the number of people doing code reviews.
> > > >
> > > > If there aren't enough people doing PR's, then people can complain on
> > > dev@
> > > > asking for review.
> > > >
> > > > -Chris
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org>
> > wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > On 2018-01-12 10:10, kellen sunderland <
> kellen.sunderland@gmail.com>
> > > > > wrote:
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <
> steffenrochel@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > I propose to adopt the proposal.
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Steffen
> > > > > > >
> > > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com>
> > wrote:
> > > > > > >
> > > > > > > > Hi Isabel,
> > > > > > > >
> > > > > > > > My apologies that not saying that clearly.
> > > > > > > >
> > > > > > > > The purpose of this proposal is encouraging more contributors
> > to
> > > > help
> > > > > > > > review and merge PRs. And also hope to shorten the time for a
> > PR
> > > to
> > > > > be
> > > > > > > > merged. After assigning maintainers to modules, then PR
> > > > contributors
> > > > > can
> > > > > > > > easily contact the reviewers. In other words, github will
> > > > > automatically
> > > > > > > > assign the PR to the maintainer and send a notification
> email.
> > > > > > > >
> > > > > > > > I don't think I put the term "inbox" in my proposal. I never
> > > > > discussed
> > > > > > > PRs
> > > > > > > > with other contributors by sending email directly, which is
> > less
> > > > > > > effective
> > > > > > > > than just using github. I also don't aware any other
> > contributor
> > > > use
> > > > > the
> > > > > > > > direct email way. So I didn't clarify it on the proposal.
> > > > > > > >
> > > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > > > > isabel@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > > muli.cmu@gmail.com
> > > > >:
> > > > > > > > > >We should encourage to contract a specific contributor for
> > > > issues
> > > > > and
> > > > > > > > > >PRs.
> > > > > > > > >
> > > > > > > > > My head translates "encourage to contact specific
> > contributor"
> > > > into
> > > > > > > > > "encourage to contact specific contributors inbox". This
> > > > translated
> > > > > > > > version
> > > > > > > > > is what I would highly discourage.
> > > > > > > > >
> > > > > > > > > See the disclaimer here for reasons behind that:
> > > > > > > > >
> > > > > > > > > https://home.apache.org/~hossman/#private_q
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Isabel
> > > > > > > > > --
> > > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> > > > > gesendet.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Marco de Abreu <ma...@googlemail.com>.
I agree. How about we find another way to allow people to subscribe for
changes in a specific file or directory?
-Marco
Am 12.01.2018 8:51 nachm. schrieb "Chris Olivier" <cj...@gmail.com>:
> Have you read "The Cathedral and the Bazaar"?
>
> http://www.unterstein.net/su/docs/CathBaz.pdf
>
> One of the points I took from this is that once a project finds its stride,
> it actually runs more efficiently without centralization than with.
>
> -Chris
>
> On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
> marco.g.abreu@googlemail.com> wrote:
>
> > Hi Chris,
> >
> > you have a good point about people being afraid of reviewing PRs which
> they
> > are not assigned to and I totally agree that we should encourage
> everybody
> > to review PRs.
> >
> > One important advantage I see in this is the notification: since we are
> not
> > using the feature to required an approval, this step is entirely for
> > information purpose. I, for example, would like to get notified if a PR
> to
> > change a CI file would be created. Just as an example: over Christmas, a
> PR
> > to update mkl has been pushed without me knowing about it. Somehow, after
> > my vacation, we started to get issues with mkl test - I only found out
> > about this PR after quite a long investigation. If we would extend the
> > usage of the code maintainers, we'll make sure that changes like these
> will
> > notify the people who have the best knowledge about that part.
> >
> > Marco
> >
> > Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <cjolivier01@gmail.com
> >:
> >
> > > -1 (binding)
> > >
> > > I totally understand the motivation for this (I've definitely saved
> > myself
> > > some grief by getting called out automatically for CMakeLists.txt
> stuff,
> > > for example), but I respectfully decline for the following reason(s):
> > >
> > > I feel that defining code-owners has some negative effects.
> > >
> > > Other committers may be reluctant to start reviewing and approving PRs
> > > since they aren't the one listed, so I feel this will in the long-run
> > > reduce the number of people doing code reviews.
> > >
> > > If there aren't enough people doing PR's, then people can complain on
> > dev@
> > > asking for review.
> > >
> > > -Chris
> > >
> > >
> > >
> > >
> > > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org>
> wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On 2018-01-12 10:10, kellen sunderland <ke...@gmail.com>
> > > > wrote:
> > > > > +1 (non-binding)
> > > > >
> > > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <steffenrochel@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > I propose to adopt the proposal.
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Steffen
> > > > > >
> > > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Hi Isabel,
> > > > > > >
> > > > > > > My apologies that not saying that clearly.
> > > > > > >
> > > > > > > The purpose of this proposal is encouraging more contributors
> to
> > > help
> > > > > > > review and merge PRs. And also hope to shorten the time for a
> PR
> > to
> > > > be
> > > > > > > merged. After assigning maintainers to modules, then PR
> > > contributors
> > > > can
> > > > > > > easily contact the reviewers. In other words, github will
> > > > automatically
> > > > > > > assign the PR to the maintainer and send a notification email.
> > > > > > >
> > > > > > > I don't think I put the term "inbox" in my proposal. I never
> > > > discussed
> > > > > > PRs
> > > > > > > with other contributors by sending email directly, which is
> less
> > > > > > effective
> > > > > > > than just using github. I also don't aware any other
> contributor
> > > use
> > > > the
> > > > > > > direct email way. So I didn't clarify it on the proposal.
> > > > > > >
> > > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > > > isabel@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> > muli.cmu@gmail.com
> > > >:
> > > > > > > > >We should encourage to contract a specific contributor for
> > > issues
> > > > and
> > > > > > > > >PRs.
> > > > > > > >
> > > > > > > > My head translates "encourage to contact specific
> contributor"
> > > into
> > > > > > > > "encourage to contact specific contributors inbox". This
> > > translated
> > > > > > > version
> > > > > > > > is what I would highly discourage.
> > > > > > > >
> > > > > > > > See the disclaimer here for reasons behind that:
> > > > > > > >
> > > > > > > > https://home.apache.org/~hossman/#private_q
> > > > > > > >
> > > > > > > >
> > > > > > > > Isabel
> > > > > > > > --
> > > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> > > > gesendet.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
Have you read "The Cathedral and the Bazaar"?
http://www.unterstein.net/su/docs/CathBaz.pdf
One of the points I took from this is that once a project finds its stride,
it actually runs more efficiently without centralization than with.
-Chris
On Fri, Jan 12, 2018 at 11:10 AM, Marco de Abreu <
marco.g.abreu@googlemail.com> wrote:
> Hi Chris,
>
> you have a good point about people being afraid of reviewing PRs which they
> are not assigned to and I totally agree that we should encourage everybody
> to review PRs.
>
> One important advantage I see in this is the notification: since we are not
> using the feature to required an approval, this step is entirely for
> information purpose. I, for example, would like to get notified if a PR to
> change a CI file would be created. Just as an example: over Christmas, a PR
> to update mkl has been pushed without me knowing about it. Somehow, after
> my vacation, we started to get issues with mkl test - I only found out
> about this PR after quite a long investigation. If we would extend the
> usage of the code maintainers, we'll make sure that changes like these will
> notify the people who have the best knowledge about that part.
>
> Marco
>
> Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <cj...@gmail.com>:
>
> > -1 (binding)
> >
> > I totally understand the motivation for this (I've definitely saved
> myself
> > some grief by getting called out automatically for CMakeLists.txt stuff,
> > for example), but I respectfully decline for the following reason(s):
> >
> > I feel that defining code-owners has some negative effects.
> >
> > Other committers may be reluctant to start reviewing and approving PRs
> > since they aren't the one listed, so I feel this will in the long-run
> > reduce the number of people doing code reviews.
> >
> > If there aren't enough people doing PR's, then people can complain on
> dev@
> > asking for review.
> >
> > -Chris
> >
> >
> >
> >
> > On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org> wrote:
> >
> > > +1 (binding)
> > >
> > > On 2018-01-12 10:10, kellen sunderland <ke...@gmail.com>
> > > wrote:
> > > > +1 (non-binding)
> > > >
> > > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <st...@gmail.com>
> > > wrote:
> > > >
> > > > > I propose to adopt the proposal.
> > > > > +1 (non-binding)
> > > > >
> > > > > Steffen
> > > > >
> > > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com> wrote:
> > > > >
> > > > > > Hi Isabel,
> > > > > >
> > > > > > My apologies that not saying that clearly.
> > > > > >
> > > > > > The purpose of this proposal is encouraging more contributors to
> > help
> > > > > > review and merge PRs. And also hope to shorten the time for a PR
> to
> > > be
> > > > > > merged. After assigning maintainers to modules, then PR
> > contributors
> > > can
> > > > > > easily contact the reviewers. In other words, github will
> > > automatically
> > > > > > assign the PR to the maintainer and send a notification email.
> > > > > >
> > > > > > I don't think I put the term "inbox" in my proposal. I never
> > > discussed
> > > > > PRs
> > > > > > with other contributors by sending email directly, which is less
> > > > > effective
> > > > > > than just using github. I also don't aware any other contributor
> > use
> > > the
> > > > > > direct email way. So I didn't clarify it on the proposal.
> > > > > >
> > > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > > isabel@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <
> muli.cmu@gmail.com
> > >:
> > > > > > > >We should encourage to contract a specific contributor for
> > issues
> > > and
> > > > > > > >PRs.
> > > > > > >
> > > > > > > My head translates "encourage to contact specific contributor"
> > into
> > > > > > > "encourage to contact specific contributors inbox". This
> > translated
> > > > > > version
> > > > > > > is what I would highly discourage.
> > > > > > >
> > > > > > > See the disclaimer here for reasons behind that:
> > > > > > >
> > > > > > > https://home.apache.org/~hossman/#private_q
> > > > > > >
> > > > > > >
> > > > > > > Isabel
> > > > > > > --
> > > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> > > gesendet.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Marco de Abreu <ma...@googlemail.com>.
Hi Chris,
you have a good point about people being afraid of reviewing PRs which they
are not assigned to and I totally agree that we should encourage everybody
to review PRs.
One important advantage I see in this is the notification: since we are not
using the feature to required an approval, this step is entirely for
information purpose. I, for example, would like to get notified if a PR to
change a CI file would be created. Just as an example: over Christmas, a PR
to update mkl has been pushed without me knowing about it. Somehow, after
my vacation, we started to get issues with mkl test - I only found out
about this PR after quite a long investigation. If we would extend the
usage of the code maintainers, we'll make sure that changes like these will
notify the people who have the best knowledge about that part.
Marco
Am 12.01.2018 8:03 nachm. schrieb "Chris Olivier" <cj...@gmail.com>:
> -1 (binding)
>
> I totally understand the motivation for this (I've definitely saved myself
> some grief by getting called out automatically for CMakeLists.txt stuff,
> for example), but I respectfully decline for the following reason(s):
>
> I feel that defining code-owners has some negative effects.
>
> Other committers may be reluctant to start reviewing and approving PRs
> since they aren't the one listed, so I feel this will in the long-run
> reduce the number of people doing code reviews.
>
> If there aren't enough people doing PR's, then people can complain on dev@
> asking for review.
>
> -Chris
>
>
>
>
> On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org> wrote:
>
> > +1 (binding)
> >
> > On 2018-01-12 10:10, kellen sunderland <ke...@gmail.com>
> > wrote:
> > > +1 (non-binding)
> > >
> > > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <st...@gmail.com>
> > wrote:
> > >
> > > > I propose to adopt the proposal.
> > > > +1 (non-binding)
> > > >
> > > > Steffen
> > > >
> > > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com> wrote:
> > > >
> > > > > Hi Isabel,
> > > > >
> > > > > My apologies that not saying that clearly.
> > > > >
> > > > > The purpose of this proposal is encouraging more contributors to
> help
> > > > > review and merge PRs. And also hope to shorten the time for a PR to
> > be
> > > > > merged. After assigning maintainers to modules, then PR
> contributors
> > can
> > > > > easily contact the reviewers. In other words, github will
> > automatically
> > > > > assign the PR to the maintainer and send a notification email.
> > > > >
> > > > > I don't think I put the term "inbox" in my proposal. I never
> > discussed
> > > > PRs
> > > > > with other contributors by sending email directly, which is less
> > > > effective
> > > > > than just using github. I also don't aware any other contributor
> use
> > the
> > > > > direct email way. So I didn't clarify it on the proposal.
> > > > >
> > > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> > isabel@apache.org>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <muli.cmu@gmail.com
> >:
> > > > > > >We should encourage to contract a specific contributor for
> issues
> > and
> > > > > > >PRs.
> > > > > >
> > > > > > My head translates "encourage to contact specific contributor"
> into
> > > > > > "encourage to contact specific contributors inbox". This
> translated
> > > > > version
> > > > > > is what I would highly discourage.
> > > > > >
> > > > > > See the disclaimer here for reasons behind that:
> > > > > >
> > > > > > https://home.apache.org/~hossman/#private_q
> > > > > >
> > > > > >
> > > > > > Isabel
> > > > > > --
> > > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> > gesendet.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Chris Olivier <cj...@gmail.com>.
-1 (binding)
I totally understand the motivation for this (I've definitely saved myself
some grief by getting called out automatically for CMakeLists.txt stuff,
for example), but I respectfully decline for the following reason(s):
I feel that defining code-owners has some negative effects.
Other committers may be reluctant to start reviewing and approving PRs
since they aren't the one listed, so I feel this will in the long-run
reduce the number of people doing code reviews.
If there aren't enough people doing PR's, then people can complain on dev@
asking for review.
-Chris
On Fri, Jan 12, 2018 at 10:41 AM, Haibin Lin <ha...@apache.org> wrote:
> +1 (binding)
>
> On 2018-01-12 10:10, kellen sunderland <ke...@gmail.com>
> wrote:
> > +1 (non-binding)
> >
> > On Jan 12, 2018 6:32 PM, "Steffen Rochel" <st...@gmail.com>
> wrote:
> >
> > > I propose to adopt the proposal.
> > > +1 (non-binding)
> > >
> > > Steffen
> > >
> > > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com> wrote:
> > >
> > > > Hi Isabel,
> > > >
> > > > My apologies that not saying that clearly.
> > > >
> > > > The purpose of this proposal is encouraging more contributors to help
> > > > review and merge PRs. And also hope to shorten the time for a PR to
> be
> > > > merged. After assigning maintainers to modules, then PR contributors
> can
> > > > easily contact the reviewers. In other words, github will
> automatically
> > > > assign the PR to the maintainer and send a notification email.
> > > >
> > > > I don't think I put the term "inbox" in my proposal. I never
> discussed
> > > PRs
> > > > with other contributors by sending email directly, which is less
> > > effective
> > > > than just using github. I also don't aware any other contributor use
> the
> > > > direct email way. So I didn't clarify it on the proposal.
> > > >
> > > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <
> isabel@apache.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
> > > > > >We should encourage to contract a specific contributor for issues
> and
> > > > > >PRs.
> > > > >
> > > > > My head translates "encourage to contact specific contributor" into
> > > > > "encourage to contact specific contributors inbox". This translated
> > > > version
> > > > > is what I would highly discourage.
> > > > >
> > > > > See the disclaimer here for reasons behind that:
> > > > >
> > > > > https://home.apache.org/~hossman/#private_q
> > > > >
> > > > >
> > > > > Isabel
> > > > > --
> > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> gesendet.
> > > > >
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by Haibin Lin <ha...@apache.org>.
+1 (binding)
On 2018-01-12 10:10, kellen sunderland <ke...@gmail.com> wrote:
> +1 (non-binding)
>
> On Jan 12, 2018 6:32 PM, "Steffen Rochel" <st...@gmail.com> wrote:
>
> > I propose to adopt the proposal.
> > +1 (non-binding)
> >
> > Steffen
> >
> > On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com> wrote:
> >
> > > Hi Isabel,
> > >
> > > My apologies that not saying that clearly.
> > >
> > > The purpose of this proposal is encouraging more contributors to help
> > > review and merge PRs. And also hope to shorten the time for a PR to be
> > > merged. After assigning maintainers to modules, then PR contributors can
> > > easily contact the reviewers. In other words, github will automatically
> > > assign the PR to the maintainer and send a notification email.
> > >
> > > I don't think I put the term "inbox" in my proposal. I never discussed
> > PRs
> > > with other contributors by sending email directly, which is less
> > effective
> > > than just using github. I also don't aware any other contributor use the
> > > direct email way. So I didn't clarify it on the proposal.
> > >
> > > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <is...@apache.org>
> > > wrote:
> > >
> > > >
> > > >
> > > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
> > > > >We should encourage to contract a specific contributor for issues and
> > > > >PRs.
> > > >
> > > > My head translates "encourage to contact specific contributor" into
> > > > "encourage to contact specific contributors inbox". This translated
> > > version
> > > > is what I would highly discourage.
> > > >
> > > > See the disclaimer here for reasons behind that:
> > > >
> > > > https://home.apache.org/~hossman/#private_q
> > > >
> > > >
> > > > Isabel
> > > > --
> > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> > > >
> > >
> >
>
Re: Module maintainers proposal
Posted by kellen sunderland <ke...@gmail.com>.
+1 (non-binding)
On Jan 12, 2018 6:32 PM, "Steffen Rochel" <st...@gmail.com> wrote:
> I propose to adopt the proposal.
> +1 (non-binding)
>
> Steffen
>
> On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com> wrote:
>
> > Hi Isabel,
> >
> > My apologies that not saying that clearly.
> >
> > The purpose of this proposal is encouraging more contributors to help
> > review and merge PRs. And also hope to shorten the time for a PR to be
> > merged. After assigning maintainers to modules, then PR contributors can
> > easily contact the reviewers. In other words, github will automatically
> > assign the PR to the maintainer and send a notification email.
> >
> > I don't think I put the term "inbox" in my proposal. I never discussed
> PRs
> > with other contributors by sending email directly, which is less
> effective
> > than just using github. I also don't aware any other contributor use the
> > direct email way. So I didn't clarify it on the proposal.
> >
> > On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <is...@apache.org>
> > wrote:
> >
> > >
> > >
> > > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
> > > >We should encourage to contract a specific contributor for issues and
> > > >PRs.
> > >
> > > My head translates "encourage to contact specific contributor" into
> > > "encourage to contact specific contributors inbox". This translated
> > version
> > > is what I would highly discourage.
> > >
> > > See the disclaimer here for reasons behind that:
> > >
> > > https://home.apache.org/~hossman/#private_q
> > >
> > >
> > > Isabel
> > > --
> > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> > >
> >
>
Re: Module maintainers proposal
Posted by Steffen Rochel <st...@gmail.com>.
I propose to adopt the proposal.
+1 (non-binding)
Steffen
On Wed, Jan 10, 2018 at 8:39 PM Mu Li <mu...@gmail.com> wrote:
> Hi Isabel,
>
> My apologies that not saying that clearly.
>
> The purpose of this proposal is encouraging more contributors to help
> review and merge PRs. And also hope to shorten the time for a PR to be
> merged. After assigning maintainers to modules, then PR contributors can
> easily contact the reviewers. In other words, github will automatically
> assign the PR to the maintainer and send a notification email.
>
> I don't think I put the term "inbox" in my proposal. I never discussed PRs
> with other contributors by sending email directly, which is less effective
> than just using github. I also don't aware any other contributor use the
> direct email way. So I didn't clarify it on the proposal.
>
> On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <is...@apache.org>
> wrote:
>
> >
> >
> > Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
> > >We should encourage to contract a specific contributor for issues and
> > >PRs.
> >
> > My head translates "encourage to contact specific contributor" into
> > "encourage to contact specific contributors inbox". This translated
> version
> > is what I would highly discourage.
> >
> > See the disclaimer here for reasons behind that:
> >
> > https://home.apache.org/~hossman/#private_q
> >
> >
> > Isabel
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >
>
Re: Module maintainers proposal
Posted by Mu Li <mu...@gmail.com>.
Hi Isabel,
My apologies that not saying that clearly.
The purpose of this proposal is encouraging more contributors to help
review and merge PRs. And also hope to shorten the time for a PR to be
merged. After assigning maintainers to modules, then PR contributors can
easily contact the reviewers. In other words, github will automatically
assign the PR to the maintainer and send a notification email.
I don't think I put the term "inbox" in my proposal. I never discussed PRs
with other contributors by sending email directly, which is less effective
than just using github. I also don't aware any other contributor use the
direct email way. So I didn't clarify it on the proposal.
On Tue, Jan 9, 2018 at 11:47 AM, Isabel Drost-Fromm <is...@apache.org>
wrote:
>
>
> Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
> >We should encourage to contract a specific contributor for issues and
> >PRs.
>
> My head translates "encourage to contact specific contributor" into
> "encourage to contact specific contributors inbox". This translated version
> is what I would highly discourage.
>
> See the disclaimer here for reasons behind that:
>
> https://home.apache.org/~hossman/#private_q
>
>
> Isabel
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>
Re: Module maintainers proposal
Posted by Pedro Larroy <pe...@gmail.com>.
Hi all.
Great initiative with maintainers, I hope to see more maintainers for
different modules. I'm happy to volunteer as well to help.
My main concern is that PRs take a long time for code to get merged,
even when changes are trivial.
I would like to see lower turn around times for simple PRs, ideally
one or max two days. Right now the average is a couple of weeks.
Why does it take so long to merge code and what can we do about it?
For me and my team this is a bit of a problem right now.
This initiative needs more people to be able to scale. Please get this
situation improved, it would greatly help the project.
Pedro.
On Tue, Jan 9, 2018 at 8:47 PM, Isabel Drost-Fromm <is...@apache.org> wrote:
>
>
> Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
>>We should encourage to contract a specific contributor for issues and
>>PRs.
>
> My head translates "encourage to contact specific contributor" into "encourage to contact specific contributors inbox". This translated version is what I would highly discourage.
>
> See the disclaimer here for reasons behind that:
>
> https://home.apache.org/~hossman/#private_q
>
>
> Isabel
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Module maintainers proposal
Posted by Isabel Drost-Fromm <is...@apache.org>.
Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li <mu...@gmail.com>:
>We should encourage to contract a specific contributor for issues and
>PRs.
My head translates "encourage to contact specific contributor" into "encourage to contact specific contributors inbox". This translated version is what I would highly discourage.
See the disclaimer here for reasons behind that:
https://home.apache.org/~hossman/#private_q
Isabel
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Module maintainers proposal
Posted by Mu Li <mu...@gmail.com>.
Hi Isabel,
Thanks for the suggestions, they are quite useful. By module maintainer I
mainly mean:
- The default PR reviewer for a module
- The default person answering questions regarding a module
We should encourage to contract a specific contributor for issues and PRs.
But if it is not clear, then ask the maintainer instead who may help
directly or reassign to another contributor.
Best
Mu
On Tue, Jan 9, 2018 at 12:35 AM, Isabel Drost-Fromm <is...@apache.org>
wrote:
> Another two side notes:
>
> Even if there are maintainers, if for instance there's a security issue in
> module X the entire PMC will be held accountable for fixing it. So for
> instance the maintainer being offline is no excuse for not taking care of
> it. "That's not my issue" is not a valid answer.
>
> Even if there are maintainers this still means other committers continue
> to have a say in reviewing that modules code even if they aren't
> maintainers.
>
> Also make sure that what you write into the maintainer docs reflects
> reality and keep things updated. Otherwise you risk things falling through
> the cracks.
>
> Think twice or more about establishing anything that could encourage
> people to get in touch with maintainers directly instead of talking with
> the project as a whole via its mailing lists (and issues/ PRs mapped to
> mailing lists). Getting rid of project content from your inbox is
> incredibly hard once you want to be less involved with the project. From a
> projects perspective extracting knowledge hidden in private inboxes is
> neigh impossible after the fact. (I have been burnt with the above more
> than once, happy to share the story of anyone is interested in listening.)
>
> Stepping down from my soap box,
> Isabel
>
> Am 9. Januar 2018 09:05:50 MEZ schrieb Sebastian <ssc.open@googlemail.com
> >:
> >One side note on the language used here: there are no "owners" of
> >packages in Apache projects, the community owns the code as a whole.
> >You
> >probably meant maintainer instead of owner.
> >
> >Best,
> >Sebastian
> >
> >On 09.01.2018 08:24, YiZhi Liu wrote:
> >> +1 for adding @CodingCat (Nan Zhu) as owner of Scala package.
> >>
> >> 2018-01-08 21:58 GMT-08:00 Mu Li <mu...@gmail.com>:
> >>
> >>> It has been a while for discussing having maintainers for individual
> >>> modules. A maintainer for a module will be the main person who
> >reviews and
> >>> approves PRs contributed to that module.
> >>>
> >>> Currently, some maintainers are listed in the file CODEOWNERS
> >>> <https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>:
> >>>
> >>> # Owners of Apache MXNet
> >>> # Global owners
> >>> * @apache/mxnet-committers
> >>> # Owners of language bindings
> >>> R-package/* @thirdwing
> >>> scala-package/* @javelinjs
> >>> perl-package/* @sergeykolychev
> >>> # CMake owners
> >>> CMakeLists.txt @cjolivier01
> >>> cmake/* @cjolivier01
> >>>
> >>> However, this list is incomplete. This document proposes how to
> >partition
> >>> mxnet codes into modules and put tentative maintainers for each
> >module.
> >>>
> >>> - I tried to select the activate contributor who contributed
> >most to the
> >>> module, not the new contributor who is going to work for it. But
> >I may
> >>> be
> >>> outdated.
> >>> - Code review is not easy. So maintainers may need help at the
> >>> beginning.
> >>> - Eric (@piiswrong) did most PR reviews, so I didn't put his
> >name on
> >>> every module.
> >>>
> >>> Any suggestion is welcome.
> >>> FrontendPYTHON: @szha
> >>>
> >>> python/
> >>>
> >>> R: @thirdwing @hetong007
> >>>
> >>> R-package/
> >>>
> >>> SCALA: @CodingCat @javelinjs
> >>>
> >>> scala-package/
> >>>
> >>> PERL@sergeykolychev
> >>>
> >>> perl-package/
> >>>
> >>> C++?
> >>>
> >>> cpp-package/
> >>>
> >>> MATLAB: DEPRECATE IT?
> >>>
> >>> matlab/
> >>>
> >>> AMALGAMATION: DEPRECATE IT?
> >>>
> >>> amalgamation/
> >>>
> >>> Backend@reminisce @eric-haibin-lin
> >>>
> >>> include/
> >>> src/
> >>>
> >>> Build@cjolivier01
> >>>
> >>> docker/
> >>> docker_multiarch/
> >>> make/
> >>> Makefile
> >>> cmake/
> >>> CMakeLists.txt
> >>> setup-utils/
> >>> prepare_mkl.sh
> >>>
> >>> Test@marcoabreu
> >>>
> >>> tests/
> >>> Jenkinsfile
> >>>
> >>> Doc & Website@kevinthesun
> >>>
> >>> docs/
> >>>
> >>> ExamplesNot sure, since we have a lot of contributors here. We
> >probably
> >>> need to remove low quality examples and assign one maintainer for
> >each of
> >>> the rest.
> >>>
> >>> example/
> >>>
> >>> ToolsNot sure as well, since we have a bunch of things there.
> >Probably need
> >>> to the same thing as examples
> >>>
> >>> tools/
> >>> plugin/
> >>>
> >>> AppendixLines of codes added into each folder on the last two
> >months:
> >>> Lines of codes added into example/
> >>> Lines of codes added into src/
> >>>
> >>
> >>
> >>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Module maintainers proposal
Posted by Isabel Drost-Fromm <is...@apache.org>.
Another two side notes:
Even if there are maintainers, if for instance there's a security issue in module X the entire PMC will be held accountable for fixing it. So for instance the maintainer being offline is no excuse for not taking care of it. "That's not my issue" is not a valid answer.
Even if there are maintainers this still means other committers continue to have a say in reviewing that modules code even if they aren't maintainers.
Also make sure that what you write into the maintainer docs reflects reality and keep things updated. Otherwise you risk things falling through the cracks.
Think twice or more about establishing anything that could encourage people to get in touch with maintainers directly instead of talking with the project as a whole via its mailing lists (and issues/ PRs mapped to mailing lists). Getting rid of project content from your inbox is incredibly hard once you want to be less involved with the project. From a projects perspective extracting knowledge hidden in private inboxes is neigh impossible after the fact. (I have been burnt with the above more than once, happy to share the story of anyone is interested in listening.)
Stepping down from my soap box,
Isabel
Am 9. Januar 2018 09:05:50 MEZ schrieb Sebastian <ss...@googlemail.com>:
>One side note on the language used here: there are no "owners" of
>packages in Apache projects, the community owns the code as a whole.
>You
>probably meant maintainer instead of owner.
>
>Best,
>Sebastian
>
>On 09.01.2018 08:24, YiZhi Liu wrote:
>> +1 for adding @CodingCat (Nan Zhu) as owner of Scala package.
>>
>> 2018-01-08 21:58 GMT-08:00 Mu Li <mu...@gmail.com>:
>>
>>> It has been a while for discussing having maintainers for individual
>>> modules. A maintainer for a module will be the main person who
>reviews and
>>> approves PRs contributed to that module.
>>>
>>> Currently, some maintainers are listed in the file CODEOWNERS
>>> <https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>:
>>>
>>> # Owners of Apache MXNet
>>> # Global owners
>>> * @apache/mxnet-committers
>>> # Owners of language bindings
>>> R-package/* @thirdwing
>>> scala-package/* @javelinjs
>>> perl-package/* @sergeykolychev
>>> # CMake owners
>>> CMakeLists.txt @cjolivier01
>>> cmake/* @cjolivier01
>>>
>>> However, this list is incomplete. This document proposes how to
>partition
>>> mxnet codes into modules and put tentative maintainers for each
>module.
>>>
>>> - I tried to select the activate contributor who contributed
>most to the
>>> module, not the new contributor who is going to work for it. But
>I may
>>> be
>>> outdated.
>>> - Code review is not easy. So maintainers may need help at the
>>> beginning.
>>> - Eric (@piiswrong) did most PR reviews, so I didn't put his
>name on
>>> every module.
>>>
>>> Any suggestion is welcome.
>>> FrontendPYTHON: @szha
>>>
>>> python/
>>>
>>> R: @thirdwing @hetong007
>>>
>>> R-package/
>>>
>>> SCALA: @CodingCat @javelinjs
>>>
>>> scala-package/
>>>
>>> PERL@sergeykolychev
>>>
>>> perl-package/
>>>
>>> C++?
>>>
>>> cpp-package/
>>>
>>> MATLAB: DEPRECATE IT?
>>>
>>> matlab/
>>>
>>> AMALGAMATION: DEPRECATE IT?
>>>
>>> amalgamation/
>>>
>>> Backend@reminisce @eric-haibin-lin
>>>
>>> include/
>>> src/
>>>
>>> Build@cjolivier01
>>>
>>> docker/
>>> docker_multiarch/
>>> make/
>>> Makefile
>>> cmake/
>>> CMakeLists.txt
>>> setup-utils/
>>> prepare_mkl.sh
>>>
>>> Test@marcoabreu
>>>
>>> tests/
>>> Jenkinsfile
>>>
>>> Doc & Website@kevinthesun
>>>
>>> docs/
>>>
>>> ExamplesNot sure, since we have a lot of contributors here. We
>probably
>>> need to remove low quality examples and assign one maintainer for
>each of
>>> the rest.
>>>
>>> example/
>>>
>>> ToolsNot sure as well, since we have a bunch of things there.
>Probably need
>>> to the same thing as examples
>>>
>>> tools/
>>> plugin/
>>>
>>> AppendixLines of codes added into each folder on the last two
>months:
>>> Lines of codes added into example/
>>> Lines of codes added into src/
>>>
>>
>>
>>
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Module maintainers proposal
Posted by Sebastian <ss...@googlemail.com>.
One side note on the language used here: there are no "owners" of
packages in Apache projects, the community owns the code as a whole. You
probably meant maintainer instead of owner.
Best,
Sebastian
On 09.01.2018 08:24, YiZhi Liu wrote:
> +1 for adding @CodingCat (Nan Zhu) as owner of Scala package.
>
> 2018-01-08 21:58 GMT-08:00 Mu Li <mu...@gmail.com>:
>
>> It has been a while for discussing having maintainers for individual
>> modules. A maintainer for a module will be the main person who reviews and
>> approves PRs contributed to that module.
>>
>> Currently, some maintainers are listed in the file CODEOWNERS
>> <https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>:
>>
>> # Owners of Apache MXNet
>> # Global owners
>> * @apache/mxnet-committers
>> # Owners of language bindings
>> R-package/* @thirdwing
>> scala-package/* @javelinjs
>> perl-package/* @sergeykolychev
>> # CMake owners
>> CMakeLists.txt @cjolivier01
>> cmake/* @cjolivier01
>>
>> However, this list is incomplete. This document proposes how to partition
>> mxnet codes into modules and put tentative maintainers for each module.
>>
>> - I tried to select the activate contributor who contributed most to the
>> module, not the new contributor who is going to work for it. But I may
>> be
>> outdated.
>> - Code review is not easy. So maintainers may need help at the
>> beginning.
>> - Eric (@piiswrong) did most PR reviews, so I didn't put his name on
>> every module.
>>
>> Any suggestion is welcome.
>> FrontendPYTHON: @szha
>>
>> python/
>>
>> R: @thirdwing @hetong007
>>
>> R-package/
>>
>> SCALA: @CodingCat @javelinjs
>>
>> scala-package/
>>
>> PERL@sergeykolychev
>>
>> perl-package/
>>
>> C++?
>>
>> cpp-package/
>>
>> MATLAB: DEPRECATE IT?
>>
>> matlab/
>>
>> AMALGAMATION: DEPRECATE IT?
>>
>> amalgamation/
>>
>> Backend@reminisce @eric-haibin-lin
>>
>> include/
>> src/
>>
>> Build@cjolivier01
>>
>> docker/
>> docker_multiarch/
>> make/
>> Makefile
>> cmake/
>> CMakeLists.txt
>> setup-utils/
>> prepare_mkl.sh
>>
>> Test@marcoabreu
>>
>> tests/
>> Jenkinsfile
>>
>> Doc & Website@kevinthesun
>>
>> docs/
>>
>> ExamplesNot sure, since we have a lot of contributors here. We probably
>> need to remove low quality examples and assign one maintainer for each of
>> the rest.
>>
>> example/
>>
>> ToolsNot sure as well, since we have a bunch of things there. Probably need
>> to the same thing as examples
>>
>> tools/
>> plugin/
>>
>> AppendixLines of codes added into each folder on the last two months:
>> Lines of codes added into example/
>> Lines of codes added into src/
>>
>
>
>
Re: Module maintainers proposal
Posted by Marco de Abreu <ma...@googlemail.com>.
Lgtm
Am 09.01.2018 8:24 vorm. schrieb "YiZhi Liu" <ja...@gmail.com>:
> +1 for adding @CodingCat (Nan Zhu) as owner of Scala package.
>
> 2018-01-08 21:58 GMT-08:00 Mu Li <mu...@gmail.com>:
>
> > It has been a while for discussing having maintainers for individual
> > modules. A maintainer for a module will be the main person who reviews
> and
> > approves PRs contributed to that module.
> >
> > Currently, some maintainers are listed in the file CODEOWNERS
> > <https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>:
> >
> > # Owners of Apache MXNet
> > # Global owners
> > * @apache/mxnet-committers
> > # Owners of language bindings
> > R-package/* @thirdwing
> > scala-package/* @javelinjs
> > perl-package/* @sergeykolychev
> > # CMake owners
> > CMakeLists.txt @cjolivier01
> > cmake/* @cjolivier01
> >
> > However, this list is incomplete. This document proposes how to partition
> > mxnet codes into modules and put tentative maintainers for each module.
> >
> > - I tried to select the activate contributor who contributed most to
> the
> > module, not the new contributor who is going to work for it. But I may
> > be
> > outdated.
> > - Code review is not easy. So maintainers may need help at the
> > beginning.
> > - Eric (@piiswrong) did most PR reviews, so I didn't put his name on
> > every module.
> >
> > Any suggestion is welcome.
> > FrontendPYTHON: @szha
> >
> > python/
> >
> > R: @thirdwing @hetong007
> >
> > R-package/
> >
> > SCALA: @CodingCat @javelinjs
> >
> > scala-package/
> >
> > PERL@sergeykolychev
> >
> > perl-package/
> >
> > C++?
> >
> > cpp-package/
> >
> > MATLAB: DEPRECATE IT?
> >
> > matlab/
> >
> > AMALGAMATION: DEPRECATE IT?
> >
> > amalgamation/
> >
> > Backend@reminisce @eric-haibin-lin
> >
> > include/
> > src/
> >
> > Build@cjolivier01
> >
> > docker/
> > docker_multiarch/
> > make/
> > Makefile
> > cmake/
> > CMakeLists.txt
> > setup-utils/
> > prepare_mkl.sh
> >
> > Test@marcoabreu
> >
> > tests/
> > Jenkinsfile
> >
> > Doc & Website@kevinthesun
> >
> > docs/
> >
> > ExamplesNot sure, since we have a lot of contributors here. We probably
> > need to remove low quality examples and assign one maintainer for each of
> > the rest.
> >
> > example/
> >
> > ToolsNot sure as well, since we have a bunch of things there. Probably
> need
> > to the same thing as examples
> >
> > tools/
> > plugin/
> >
> > AppendixLines of codes added into each folder on the last two months:
> > Lines of codes added into example/
> > Lines of codes added into src/
> >
>
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>
Re: Module maintainers proposal
Posted by YiZhi Liu <ja...@gmail.com>.
+1 for adding @CodingCat (Nan Zhu) as owner of Scala package.
2018-01-08 21:58 GMT-08:00 Mu Li <mu...@gmail.com>:
> It has been a while for discussing having maintainers for individual
> modules. A maintainer for a module will be the main person who reviews and
> approves PRs contributed to that module.
>
> Currently, some maintainers are listed in the file CODEOWNERS
> <https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>:
>
> # Owners of Apache MXNet
> # Global owners
> * @apache/mxnet-committers
> # Owners of language bindings
> R-package/* @thirdwing
> scala-package/* @javelinjs
> perl-package/* @sergeykolychev
> # CMake owners
> CMakeLists.txt @cjolivier01
> cmake/* @cjolivier01
>
> However, this list is incomplete. This document proposes how to partition
> mxnet codes into modules and put tentative maintainers for each module.
>
> - I tried to select the activate contributor who contributed most to the
> module, not the new contributor who is going to work for it. But I may
> be
> outdated.
> - Code review is not easy. So maintainers may need help at the
> beginning.
> - Eric (@piiswrong) did most PR reviews, so I didn't put his name on
> every module.
>
> Any suggestion is welcome.
> FrontendPYTHON: @szha
>
> python/
>
> R: @thirdwing @hetong007
>
> R-package/
>
> SCALA: @CodingCat @javelinjs
>
> scala-package/
>
> PERL@sergeykolychev
>
> perl-package/
>
> C++?
>
> cpp-package/
>
> MATLAB: DEPRECATE IT?
>
> matlab/
>
> AMALGAMATION: DEPRECATE IT?
>
> amalgamation/
>
> Backend@reminisce @eric-haibin-lin
>
> include/
> src/
>
> Build@cjolivier01
>
> docker/
> docker_multiarch/
> make/
> Makefile
> cmake/
> CMakeLists.txt
> setup-utils/
> prepare_mkl.sh
>
> Test@marcoabreu
>
> tests/
> Jenkinsfile
>
> Doc & Website@kevinthesun
>
> docs/
>
> ExamplesNot sure, since we have a lot of contributors here. We probably
> need to remove low quality examples and assign one maintainer for each of
> the rest.
>
> example/
>
> ToolsNot sure as well, since we have a bunch of things there. Probably need
> to the same thing as examples
>
> tools/
> plugin/
>
> AppendixLines of codes added into each folder on the last two months:
> Lines of codes added into example/
> Lines of codes added into src/
>
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada