mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jojy Varghese <j...@mesosphere.io>
Subject Re: Working Group List
Date Thu, 24 Sep 2015 00:55:47 GMT
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 <bmahler@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 <jojy@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.mahler@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 <jojy@mesosphere.io
> > <mailto:jojy@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.mahler@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 <jojy@mesosphere.io
> > <mailto:jojy@mesosphere.io>
> > >> <mailto:jojy@mesosphere.io <mailto:jojy@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 <vinodkone@gmail.com
> > <mailto:vinodkone@gmail.com>> wrote:
> > >>>>>
> > >>>>> +1
> > >>>>>
> > >>>>> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <
> > niklas@mesosphere.io <mailto:niklas@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message