Re: [FFmpeg-devel] [PATCH 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg

[Michael Niedermayer <michael@niedermayer.cc>]

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

On Tue, Jun 18, 2024 at 12:09:34PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-06-18 01:48:25)
> > On Mon, Jun 17, 2024 at 09:07:23AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-06-17 01:08:29)
> > > > Ive been told that someone at the BCN video tech meetup claimed to be the
> > > > "release maintainer for FFmpeg".
> > > > 
> > > > If you have any doubt who maintains releases, just do something like the following and look at the output:
> > > > VER=5.1
> > > > echo commiters ; git shortlog  --group=committer -s  n$VER..release/$VER -n ;\
> > > > echo authors   ; git shortlog                    -s  n$VER..release/$VER -n
> > > 
> > > Passive aggressive gossip does not belong in a commit message.
> > 
> > we generally explain in a commit message the "why" and "what" and so on.
> > There was no intention of any aggression.
> 
> The commit message is indirectly accusing an unindentified person of
> trying to usurp your position as a release maintainer. The accusation is
> aggressive, and the fact that it is indirect makes it passive
> aggressive.
> 
> Not providing any specifics beyond "someone said that someone said"
> makes it gossip.
> 
> Each of those factors in isolation IMO makes this text inappropriate for
> a commit message.

I dont entirely agree but ill drop it from the commit message.


[...]

> > The example git commands simply show the authors and commiters on the release branch
> > since the first release on it. I think its reasonable to provide these as reference
> 
> I don't. Nobody is disputing your role as a release maintainer.

Its always nice to learn that iam A release maintainer and not THE release maintainer. :)
Which releases are maintained by someone else ?
And who is that someone else ?
Can that other release maintainer look at some of the regressions we have?
IIRC there are cases that since the multithreding dont 100% of the time
produce the same output, it makes testing more difficult. And while
already at that subject can that other release maintainer help marking
regressions as such and as release blocking ? So they are more vissible
and can get fixed.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

[-- 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".