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/>
>
> Please see the thread here:
> 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>> 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>>
>> 2. 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> wrote:
>>>
>>> +1
>>>
>>> On Fri, Sep 18, 2015 at 10:55 AM, Niklas Nielsen <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
