Re: [RFC PATCH 1/4] docs/devel: add a maintainers section to development process

["Alex Bennée" <alex.bennee@linaro.org>]

Markus Armbruster <armbru@redhat.com> writes:

> Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
>
>> On 12/10/2022 13:11, Alex Bennée wrote:
>
> [...]
>
>>> +Becoming a maintainer
>>> +---------------------
>>> +
>>> +Maintainers are volunteers who put themselves forward to keep an eye
>>> +on an area of code. They are generally accepted by the community to
>
> Do you mean "expected by the community"?

Well I was trying to make clear how the "community" decides who should
be a maintainer. We don't leave it to who's currently holding the merge
keys so in practice its other contributors acknowledging that the
proposed maintainer knows their stuff (or at least didn't step backwards
fast enough when the call went out).

In practice when maintainership is passed down this is often just the
R-b by the previous maintainer. For areas where no maintainer currently
exists just gathering a few R-b's seems to be enough because having a
maintainer is better than not having one.

>
>>> +have a good understanding of the subsystem and able to make a positive
>>> +contribution to the project.
>>
>> Is it worth making this a bit stronger such as "having a
>> demonstrable track record of providing accepted upstream patches"?
>> I'm not sure if this is being a bit too
>> nit-picky, however someone could have good understanding of a
>> subsystem such as PCI but be still unfamiliar with the QEMU's PCI
>> APIs and how they should be used.
>
> I think existing practice varies.
>
> For something that is widely used, we generally require enough of a
> track record (contributions *and* reviews) to inspire confidence.

I can certainly add language about prior contributions. 

> But if you submit something new, say a machine, we may ask you to stick
> around and maintain it as a prerequisite for merging.
>
> [...]


-- 
Alex Bennée