I see, could you start a thread about the difficulties so that we can explore them further?
I just want to avoid hijacking this thread as these should be discussed independently. I will share my thoughts there, as I'm sure others will :) On Wed, Sep 23, 2015 at 4:54 PM, Jojy Varghese <[email protected]> wrote: > The proposal lists the motivations in the "problem statement” section. > > -Jojy > > > > On Sep 23, 2015, at 4:27 PM, Benjamin Mahler <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 < > [email protected]> > >> 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 <[email protected] > <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] > <mailto:[email protected]>> wrote: > >>>>> > >>>>> +1 > >>>>> > >>>>> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen < > [email protected] <mailto:[email protected]> > >>> > >>>>> 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 > >
