> On May 17, 2015, 7:03 a.m., Adam B wrote: > > Thank you for putting this together. This will help people decide where to > > turn when they need advice or a shepherd/reviewer. > > Please allow me to suggest some additional components and maintainers, and > > clarify some terminology/formatting.
My pleasure and thanks for the feedback! Really appreciate the time you took. I'm hoping that this serves as a resource for those newer contributors and committers. Per your feedback, I've trimmed this down. Let's iterate on what should be in here as things play out! The balancing act here is that we don't ever want the concept of maintainers to lead to silos or ownership. Rather, it should just reflect where folks can seek feedback when they are not feeling comfortable with a particular area of the code base. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 217 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line217> > > > > Nominating: dlester We have been making committers accountable for doing documentation as part of releasing a feature. For example, auth, reconciliation, network monitoring, etc all had documents added as part of the development. In this sense documentation mirrors many aspects of the project and so maintainers is really wide here: it depends on the document! I'll remove this one, since I agree we should only list the ones that are not widely maintained. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, lines 252-256 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line252> > > > > There were talks of moving the CLI and/or WebUI outside of the repo, > > for external maintenance. Then we wouldn't necessarily need Apache Mesos > > committers to maintain it/them. That means no webui and CLI out of the box, which is a fairly substantial decision that we should weigh in the public. I wasn't aware of these talks :) > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 245 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line245> > > > > I'll volunteer to help out here, if you'll have me. Sounds good! > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 206 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line206> > > > > I looked over the JIRA project components and here are the extras I'd > > like to see covered here: > > - allocation > > - fetcher > > - project website (dlester) > > - statistics (dhamon?) - Allocation is captured under "master", I didn't pull apart master and slave components (e.g. registrar, status update manager, etc) because the maintainers would be no different. Going forward if this turns out to be no longer the case we can consider splitting :) - Fetcher is a very simple component currently; if there were maintainers for fetcher it would follow that there would be a lot more components listed here. So I've only tried to capture a broad collection of components here in the first cut. Those things that are difficult for someone fresh to approach. - Sounds good, I will add dave for the project website due to the complexity there. I initially held off because it is outside the git repository, but it does seem good to surface that there really is only 1 person who understands it! Also, we're planning to have it moved in to the git respository once supported by INFRA. - Statistics as in metrics from libprocess? I don't think that warrants having a specific maintainer, otherwise it follows to have maintainers for things like Future, Subprocess, etc but IMHO that would be way too fine-grained for the intent here. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 221 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line221> > > > > Does the ordering mean anything here? When reading it, I assume that > > the first person listed is the person I should bother first, which is BenH > > on 8 different components. In fact, there are only 2 components with > > maintainers where BenH is not on the list. > > I would hope that, over time, we can balance out the maintainers list > > so that nobody is primary maintainer for more than a few components. This > > will ease the load on the busiest committers. That is indeed the hope! The point of this exercise is to just surface the existing conditions, where we definitely have imbalances in maintainers. We should strive to balance things out over time, of course! Again, this is not a stamping process, it is a resource for feedback when deemed necessary. It's alphabetical, similar to how I've seen it done in other projects (e.g. spark). I'm guessing projects shy away from an ordered listing because the order changes over time, depending on how busy folks are, etc. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 197 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line197> > > > > I'm not sure I'm bought into this "widely maintained components" > > terminology or philosophy. I agree that everybody should maintain the > > tests, but "tests" isn't even listed as a component, presumably for that > > reason. > > "Build and support tooling", however, is listed as a component, and > > there are definitely some I would consult about build issues or > > reviewbot/mesos-style before others. Same goes for documentation. > > > > As you mention just before, everyone is responsible for the entire > > codebase, so there's no need to list the "widely maintained" components. > > Let's only call out "components" here where there are individual committers > > with increased context/interest/perspective. Sounds good, I'll pull out the widely maintained ones. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 213 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line213> > > > > Nominating: tstclair, vinodkone Pulled this one out per your comment above. I think if I listed folks here I would have to split it up quite a bit, since there are too many things falling into the support tooling category. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, lines 224-228 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line224> > > > > Are these really different enough to separate? I'll remove the drivers for now. > On May 17, 2015, 7:03 a.m., Adam B wrote: > > docs/committers.md, line 220 > > <https://reviews.apache.org/r/34295/diff/1/?file=961792#file961792line220> > > > > Is this the Master/Slave API, or everything in master.cpp and > > slave.cpp? If the latter, I would suggest splitting these up. If the > > former, we should say "API". Neither, this is everything in the master component and everything in the slave component (including allocation, registrar, etc in the former and status update manager, garbage collector, etc in the latter). - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34295/#review84007 ----------------------------------------------------------- On May 15, 2015, 10:25 p.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34295/ > ----------------------------------------------------------- > > (Updated May 15, 2015, 10:25 p.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Dave Lester, Ian Downes, > Jie Yu, Niklas Nielsen, Till Toenshoff, Timothy Chen, Vinod Kone, and Jiang > Yan Xu. > > > Bugs: MESOS-2737 > https://issues.apache.org/jira/browse/MESOS-2737 > > > Repository: mesos > > > Description > ------- > > Per the proposal thread, this adds documentation for maintainers and an > initial set of maintainers. > > Please share your thoughts! > > > Diffs > ----- > > docs/committers.md PRE-CREATION > docs/home.md 4b8e7f8d2dcd9e26816353c939a2a5c18314ac45 > > Diff: https://reviews.apache.org/r/34295/diff/ > > > Testing > ------- > > Markdown: https://gist.github.com/bmahler/962d1ddc9f14e1d342a6 > > > Thanks, > > Ben Mahler > >
