mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jojy Varghese <>
Subject Re: Working Group List
Date Mon, 21 Sep 2015 19:09:09 GMT
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. 

	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.


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)

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).

1. <>
2. <>



> On Sep 18, 2015, at 11:24 AM, Vinod Kone <> wrote:
> +1
> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <>
> 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:
>> 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

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