[FFmpeg-devel] GSoC 2025

[Koushik Dutta]

Why gitlab and not GitHub? If the intent is on making contribution from new
developers easier, I think the workflow should be where the majority of
developers are actively participating.


On Wed, Jan 29, 2025 at 11:32 AM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel at ffmpeg.org> wrote:

> On Wed, Jan 29, 2025 at 7:01 PM Michael Niedermayer
> <michael at 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.
>
> It's clear the contribution method is outdated and difficult to
> manage. We need to move to GitLab ASAP (the name Forgejo will put
> people off, I mean seriously, Esperanto names in 2025, what a joke)
> with proper CI. Otherwise people like the OP will be put off. I have
> lots of people on the assembly course looking at the mailing list like
> it's a fax machine.
>
> Kieran
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>