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/
Please see the thread here: 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> 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> > 2. 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 > >> > >
