Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Kieran Kunhya <kieran618@googlemail.com>
Subject: Re: [FFmpeg-devel] GSoC 2025
Date: Wed, 29 Jan 2025 19:31:45 +0000
Message-ID: <CABGuwE=9KX6EFUTUEXx27To4EqN1XrnQJJ9_-s6MNntEX9LRRA@mail.gmail.com> (raw)
In-Reply-To: <20250129190129.GA4991@pb2>

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.

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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

  reply	other threads:[~2025-01-29 19:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28  2:21 Michael Niedermayer
2025-01-29 15:51 ` Yigithan Yigit
2025-01-29 19:01   ` Michael Niedermayer
2025-01-29 19:31     ` Kieran Kunhya via ffmpeg-devel [this message]
2025-01-29 20:01       ` Ronald S. Bultje
2025-01-30  6:36         ` Vittorio Giovara
2025-01-30 10:21           ` Sean McGovern
2025-01-30 18:40       ` Michael Niedermayer
2025-01-30 21:20       ` Koushik Dutta
2025-01-30 14:53         ` compn
2025-01-31  5:01           ` Soft Works
2025-01-31  0:24         ` Vittorio Giovara
2025-01-31 12:51         ` James Almer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABGuwE=9KX6EFUTUEXx27To4EqN1XrnQJJ9_-s6MNntEX9LRRA@mail.gmail.com' \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=kieran618@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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