I would be happy to start a new thread. I had the proposal in this thread on suggestion(verbal) from Nick who started this thread. Maybe because the underlying issues are same.
-jojy On Wed, Sep 23, 2015 at 5:09 PM Benjamin Mahler <bmah...@twitter.com.invalid> wrote: > 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 <j...@mesosphere.io> wrote: > > > 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 > > > > >
