Rather than address these suggestions, I'd like to first understand the motivation behind them. Feel free to start a separate thread about any difficulties you're observing that you'd like the dev community to discuss.
On Mon, Sep 21, 2015 at 3:12 PM, Jojy Varghese <j...@mesosphere.io> wrote: > Hi Ben > The earlier proposal looks great and the new proposal is along the lines > of the earlier proposal. They differ only in how much details is provided. > > 1. Scaling > - What are the plans for having core maintainers who have domain > expertise and at the same time scaling as contributions and features grow. > 2. SLAs for maintainers > - What are the MUST do responsibilities of a maintainer and SLAs > around things like turn around time. > 3. Plan for cross-subsystem aspects and orphan submissions. > 4. Details of subsystems. Also, we might need maintainers for > sub-subsystems. > 5. Plans for engagement with maintainers. > > thanks > Jojy > > > > On Sep 21, 2015, at 2:43 PM, Benjamin Mahler <benjamin.mah...@gmail.com> > wrote: > > > > Hi Jojy, > > > > This was brought up previously on the threads and prompted the creation > of > > subcomponent maintainers, which you can find listed here: > > http://mesos.apache.org/documentation/latest/committers/ < > http://mesos.apache.org/documentation/latest/committers/> > > > > Please see the thread here: > > http://markmail.org/thread/cjmdn3d7qfzbxhpm < > http://markmail.org/thread/cjmdn3d7qfzbxhpm> > > > > It would be great if you could highlight some differences between what we > > have now and your proposal, thanks! > > > > Ben > > > > On Mon, Sep 21, 2015 at 12:09 PM, Jojy Varghese <j...@mesosphere.io > <mailto:j...@mesosphere.io>> wrote: > > > >> Proposing a subsystem-specific-maintainer model. > >> > >> > >> > >> Subsystem Specific Maintainers > >> ---- > >> > >> Problem statement > >> As Mesos project grows in terms of subsystems, features and > >> contributors, it becomes harder to scale development and maintenance > >> without a model. To list a few problems: > >> - Getting attention for a contribution (patch or any proposal) > >> becomes hard. > >> - As more subsystems are developed, it becomes hard to maintain > >> standard and context without domain knowledge experts. > >> - Some subsystems could have more velocity than others and > having > >> a uniform distribution of maintainers will have scaling problems. > >> > >> > >> Abstract > >> Open source projects have proven scalable model that works on the > >> idea of having subsystem specific maintainers. Linux kernel is a good > >> example of this model [1]. This proposal explores the possibility of > such a > >> model for Mesos project. > >> > >> Subsystems > >> > >> Possible subsystems in the Mesos project are: > >> - Allocator > >> - Master > >> - Slave > >> - Security > >> - Http endpoints > >> - Containers > >> - Storage > >> - Networking > >> - Messaging > >> - API/ABI and versioning > >> > >> These subsystems can be further subdivided into granular subsystems. > >> > >> Cross subsystem concerns > >> There could be issues and projects that span across subsystems. Some of > >> them could be: > >> - Coding guidelines > >> - System performance > >> - System testing > >> - Code analysis (coverity) > >> > >> > >> Model > >> > >> 1. View the project as a system of subsystems > >> 2. Have mailing list project page specific to the subsystem to provide > >> guidelines and context > >> 3. Have a core set of maintainers for the subsystems and have a rotation > >> of non-core maintainers. This would address two requirements: > >> - Core maintainers will have the domain expertise > >> - Rotation/on-demand maintainers will allow scale > >> 4. Have core maintainers of a subsystem also be rotated for other > >> subsystems. > >> - This will allow knowledge base distribution. > >> 5. Define a set of criteria for becoming core maintainer of a subsystem. > >> Maintainers will have to make a effort to keep their status[2]. > >> 6. As the system grows, some subsystems would be in “support” only mode > >> and some of them could be in “obsolete”/“deprecated” mode. > >> 7. Not all mails and queries would be addressed to subsystems. These > >> should be addressed by the “General” maintainers. This set of > maintainers > >> could be picked from the available pool of maintainers. > >> > >> > >> Engaging Maintainers > >> > >> Each upcoming project should engage subsystem maintainers. This will > >> enable planning for those projects. This also has other side effects - > >> - Each project/epic should be guided by proper design documents that has > >> section that lists the stakeholders. Subsystems are stakeholders. > >> - Design docs should ideally define expected behavior from subsystems > >> (SLA). > >> > >> References > >> 1. https://www.kernel.org/doc/linux/MAINTAINERS < > >> https://www.kernel.org/doc/linux/MAINTAINERS < > https://www.kernel.org/doc/linux/MAINTAINERS>> > >> 2. https://lwn.net/Articles/500443/ <https://lwn.net/Articles/500443/> > <https://lwn.net/Articles/500443/ <https://lwn.net/Articles/500443/>> > >> > >> > >> > >> ---- > >> > >> thanks > >> Jojy > >> > >> > >>> On Sep 18, 2015, at 11:24 AM, Vinod Kone <vinodk...@gmail.com> wrote: > >>> > >>> +1 > >>> > >>> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <nik...@mesosphere.io > > > >>> wrote: > >>> > >>>> Hi folks, > >>>> > >>>> Per our last community meeting, I created a list on our Confluence > Wiki > >> to > >>>> keep track of and increase visibility into the running working groups. > >>>> We have previously created these groups implicitly, and as the > community > >>>> grow, we unfortunately ended up with duplicate meetings with different > >>>> stake holders in the case of Networking and folks have been missing > out > >> on > >>>> other meetings too. > >>>> > >>>> So, here it is: > >>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups > >>>> > >>>> I imagined that we could create IRC channels, hangouts etc and note > the > >>>> channels there. > >>>> > >>>> Of course, the main activity should be on the dev@ list but we have > >>>> traditionally met up (online or IRL) for design sessions, higher > >> frequency > >>>> feedback during reviews, etc. > >>>> > >>>> Thoughts / ideas? > >>>> > >>>> Cheers, > >>>> Niklas > >
