The proposal lists the motivations in the "problem statement” section.
-Jojy > On Sep 23, 2015, at 4:27 PM, Benjamin Mahler <benjamin.mah...@gmail.com> > wrote: > > 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 > <mailto: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/ >> <http://mesos.apache.org/documentation/latest/committers/>> >>> >>> Please see the thread here: >>> http://markmail.org/thread/cjmdn3d7qfzbxhpm >>> <http://markmail.org/thread/cjmdn3d7qfzbxhpm> < >> 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> >> <mailto: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 >>>> <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/>> >> <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 >>>>> <mailto:vinodk...@gmail.com>> wrote: >>>>> >>>>> +1 >>>>> >>>>> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <nik...@mesosphere.io >>>>> <mailto: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
