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>
2. https://lwn.net/Articles/500443/ <https://lwn.net/Articles/500443/>
----
thanks
Jojy
> On Sep 18, 2015, at 11:24 AM, Vinod Kone <[email protected]> wrote:
>
> +1
>
> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <[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
>>
