Re: [FFmpeg-devel] [RFC] the role of maintainers

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3740 bytes --]

On Fri, Mar 24, 2023 at 03:29:18PM +0100, Anton Khirnov wrote:
> Hi,
> during the recent discussion on git repo push rights vs maintainership
> there was some disagreement on what does (or should) it mean to be a
> maintainer of a piece of code. It seems that different people have very
> different ideas on this, so I think it would be good to reach some kind
> of consensus.
> 
> I propose that people submit their opinions on what the rights and
> responsibilities of a maintainer should be to this thread, so their
> relative merits can be discussed.
> The we have a GA vote, and write down the result in the dev rules.
> 
> To start, some of the specific questions that I believe should be
> considered are:
> 1. Should the concept of maintainership exist at all? Does it serve a
>    useful purpose? If so, what is it?
> (further questions assume that the answer to 1. is yes)

Ultimately someone does fix issues, improve some code and takes some
responsibility related to that code, aka "caring about it"

If noone does that, well ok, you have no maintainer. OTOH if someone
does these things, thats what i would call a maintainer. The term
"maintainer" is juat a label for that. 
The same way a software developer is a label for someone creating
software. Thats at least the way i see it.


> 2. Should maintainers automatically get git push access?

maintainers should be able to work on the code they maintain with minimal friction.
In a Project using multiple git repositories which get merged they do not
need write access to anything but their repository which is merged.
For a project with a single main repository and no merges, write access
is needed to maintain (fix bugs, apply patches, ...)


> 3. Should maintainers be allowed to push to their code without sending
>    patches for review?

We dont want bugs, we dont want to hinder development speed.
The line here can be drawen in different ways and differnt places.

what i think should be clear is someone pushing without sending a patch
should
* have a good reason to do so. (like a trivial compile fix)
* be ready and available afterwards if theres an issue
* have the code tested and reviewed even if done only by him/herself


> 4. How much control do maintainers get over their code. Can they
>    override other developers' opinions or is the role merely advisory?

Awnsering this without specific cases in mind may be flawed but i would say
that in absence of a consensus, the maintainer should be the one who
can make a decission. The maintainer should have a very good understanding
of the code (s)he maintains

A situation where a large majority wants X and a single person overrides that
and does Y is a very odd situation i think. And i really think such
a case would merrit a closer look and not a static awnser. But the decission
maker here be that the majority or someone else should understand the reasoning
of both sides.


> 5. Do maintainers have duties? E.g. are they required to fix bugs in
>    their code, perform reviews, etc. Do they lose maintainership if they
>    fail to perform those?

If someone else does a better job and wants to take over (or help) with
maintainership then maintainership should shift toward that volunteer.
Ideally that should be a process all involved work togtether.
removing a maintainer when there is noone else who would take over
doesnt make much sense to me.


[...]

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".