Re: [FFmpeg-devel] GSoC 2025

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi CC

As i was speaking of infighting
this reply seems to provide a good example of the problem FFmpeg has.

But also it is insulting toward Yigithan as well as me.
As well as really misrepresenting what my mail said.

thx

On Wed, Jan 29, 2025 at 07:31:45PM +0000, Kieran Kunhya via ffmpeg-devel wrote:
> On Wed, Jan 29, 2025 at 7:01 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > Hi Yigithan
> >
> > Its good that you bring these issues up.
> > Discussing about them is a step towards solving them
> >
> > see my coments inline below
> >
> > On Wed, Jan 29, 2025 at 06:51:40PM +0300, Yigithan Yigit wrote:
> > > Hi Michael,
> > >
> > > I want to give some feedback before GSoC’25 as GSoC’24 participant. I speak for myself but I know some of other colleagues are sharing similar thoughts with me.
> > >
> > > First of all community has incredible talented people and I am not even single percent of those people. However I tried my best during the qualification stage and after that. My main problem was finding answer's inside a huge codebase. I might come stupid ideas, bad implementations but to be honest when I asked about something in IRC I couldn’t get any answers, even in my volumedetect(qual patch) I couldn’t get a proper review from community.
> > >
> >
> > > Guessing contributors are mostly the passionate driven. I find that passion beginning but lost day by day. I tried to share similar thought during VDD, they told me this is normal and happening. Which shouldn’t be in my opinion. If project wants to
> >
> > yes, i also agree that this should not happen
> >
> >
> > > newcomers or continuous contributors  people should be more welcoming. I understand you can’t force people to review some patches but still there are some parts needed to be change, I can’t say specifically which parts but they should be changed.
> >
> > Its a complex problem
> >
> > The average age of developers is becoming older, (meaning there are fewer new developers joining than in the past)
> >
> > many now are payed by companies to do specific work for a company.
> > Meaning they have less time to do what the community and FFmpeg needs
> > as they spend time to do what the company needs
> > I think people should attempt to shift payed feature implementation towards payed maintaince and
> > reviewing patches, picking up an area and maintaining it as their day job
> >
> > What is impotant is to have maintainers for every part of the codebase.
> > But to have a passionate and dedicated maintainer, often either he needs
> > to have authority or needs to be paid.
> >
> > Both we fail at. AND also it needs the mindset that maintainers are needed.
> >
> > For the payment,
> > for example carl, who took care of the bug tracker for years (something truly important)
> > should have been hired by some company to continue that work, it would have
> > made economic sense to these companies actually.
> >
> > Another example for Payment is the souvereign tech fund. last year we for the
> > first time got accepted BUT first it was really hard to find developers who
> > where willing to agree to do the work. And then there was a huge amount of
> > infighting.
> >
> > The problem is there is not a mindset of "this makes sense", "lets do it" but
> > much more a mindset of bickering on whatevr the other did.
> >
> > Also various company executives could have encouranged the employees to do
> > maintaince work for FFmpeg STF. Would have cost them 0, would have made a
> > huge difference in how many people would have been available!
> >
> > And about authority.
> > We have some developers who want to have a say in everything. That just takes
> > all passion out for some people. I also think this was a big factor why Paul forked
> >
> > So IMO, the mindset of the FFmpeg team needs to change. If one sees another
> > working on something lets say a booth or STF, or anything code related or
> > anything code unrelated the idea would be to be supportive. <--- This would help I belive
> >
> > The other change would be to draw clear lines and clearly give authority to
> > people in their area so they have some borders that shield them from things
> > that take their passion away. Which then makes them stop maintaining the code
> > and that then takes the passion of contributors away.
> >
> > Or maybe to put this another way. Try to have exactly 1 cook in every kitchen
> > If you intend to eat the resulting food.
> 
> OMG a GSoC student is complaining about how hard the contribution
> process is and you've turned it into "yet another Michael wall of
> text" that has nothing to do with the topic but instead yet another
> incoherent airing of your current grievances and the usual defence of
> your buddies.
> 

[...]
--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

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