* [FFmpeg-devel] [RFC] the role of maintainers
@ 2023-03-24 14:29 Anton Khirnov
2023-03-24 15:14 ` Paul B Mahol
2023-03-25 0:14 ` Michael Niedermayer
0 siblings, 2 replies; 4+ messages in thread
From: Anton Khirnov @ 2023-03-24 14:29 UTC (permalink / raw)
To: FFmpeg development discussions and patches
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)
2. Should maintainers automatically get git push access?
3. Should maintainers be allowed to push to their code without sending
patches for review?
4. How much control do maintainers get over their code. Can they
override other developers' opinions or is the role merely advisory?
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?
Cheers,
--
Anton Khirnov
_______________________________________________
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [FFmpeg-devel] [RFC] the role of maintainers
2023-03-24 14:29 [FFmpeg-devel] [RFC] the role of maintainers Anton Khirnov
@ 2023-03-24 15:14 ` Paul B Mahol
2023-03-25 0:14 ` Michael Niedermayer
1 sibling, 0 replies; 4+ messages in thread
From: Paul B Mahol @ 2023-03-24 15:14 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Fri, Mar 24, 2023 at 3:29 PM Anton Khirnov <anton@khirnov.net> 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?
>
Answer is No.
> (further questions assume that the answer to 1. is yes)
> 2. Should maintainers automatically get git push access?
> 3. Should maintainers be allowed to push to their code without sending
> patches for review?
> 4. How much control do maintainers get over their code. Can they
> override other developers' opinions or is the role merely advisory?
> 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?
>
> Cheers,
> --
> Anton Khirnov
> _______________________________________________
> 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".
>
_______________________________________________
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [FFmpeg-devel] [RFC] the role of maintainers
2023-03-24 14:29 [FFmpeg-devel] [RFC] the role of maintainers Anton Khirnov
2023-03-24 15:14 ` Paul B Mahol
@ 2023-03-25 0:14 ` Michael Niedermayer
2023-03-28 11:37 ` Anton Khirnov
1 sibling, 1 reply; 4+ messages in thread
From: Michael Niedermayer @ 2023-03-25 0:14 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- 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".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [FFmpeg-devel] [RFC] the role of maintainers
2023-03-25 0:14 ` Michael Niedermayer
@ 2023-03-28 11:37 ` Anton Khirnov
0 siblings, 0 replies; 4+ messages in thread
From: Anton Khirnov @ 2023-03-28 11:37 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Quoting Michael Niedermayer (2023-03-25 01:14:45)
> 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.
The question is whether we benefit from this being a formal role. You
can just as well fix issues and improve code without being called the
maintainer.
And it seems to me that your "just a label" claim is not consistent with
the rest of your reply, where you say that maintainer automatically gets
certain privileges, such as git push access.
IMO these roles should be decoupled, because someone who authored a
specific module (like a filter or decoder) might still not know how his
code interacts with the rest of the project.
--
Anton Khirnov
_______________________________________________
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-03-28 11:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-24 14:29 [FFmpeg-devel] [RFC] the role of maintainers Anton Khirnov
2023-03-24 15:14 ` Paul B Mahol
2023-03-25 0:14 ` Michael Niedermayer
2023-03-28 11:37 ` Anton Khirnov
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git