mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mu Li <muli....@gmail.com>
Subject Re: Module maintainers proposal
Date Tue, 09 Jan 2018 17:25:50 GMT
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 <isabel@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 <muli.cmu@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message