[FFmpeg-devel] GSoC 2025

[FFmpeg-devel] GSoC 2025

[Michael Niedermayer]

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

Hi

Everyone interested in mentoring a project in 2025, please add your idea(s) to [1].

during February 11 - 26 "Google program administrators review organization applications"
That means that by February 11th the list of ideas must be completed

[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2025

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What is money laundering? Its paying someone and not telling the government.

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

Re: [FFmpeg-devel] GSoC 2025

[Yigithan Yigit]

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

In addition to that I am very thankful to my 2 mentors (Thilo, Kyle) for helping me every step. I do not want to understood like my mentors didn’t help me.

Best Regards,
Yiğithan Yiğit

> On 28 Jan 2025, at 05:21, Michael Niedermayer <michael@niedermayer.cc> wrote:
> Hi
> 
> Everyone interested in mentoring a project in 2025, please add your idea(s) to [1].
> 
> during February 11 - 26 "Google program administrators review organization applications"
> That means that by February 11th the list of ideas must be completed
> 
> [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2025
> 
> thx
> 
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> What is money laundering? Its paying someone and not telling the government.
> _______________________________________________
> 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".
> <signature.asc>
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[Michael Niedermayer]

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

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.


> 
> In addition to that I am very thankful to my 2 mentors (Thilo, Kyle) for helping me every step. I do not want to understood like my mentors didn’t help me.

yes, id also like to thank them for working on GSoC

thx


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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

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

Re: [FFmpeg-devel] GSoC 2025

[Kieran Kunhya via ffmpeg-devel]

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

Re: [FFmpeg-devel] GSoC 2025

[Ronald S. Bultje]

Hi,

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

> It's clear the contribution method is outdated and difficult to
> manage. We need to move to GitLab ASAP


Yes please.

Ronald
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[Vittorio Giovara]

On Wed, Jan 29, 2025 at 9:02 PM Ronald S. Bultje <rsbultje@gmail.com> wrote:

> Hi,
>
> On Wed, Jan 29, 2025 at 2:32 PM Kieran Kunhya via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> > It's clear the contribution method is outdated and difficult to
> > manage. We need to move to GitLab ASAP
>
>
> Yes please.
>
> Ronald
>

+1
-- 
Vittorio
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[Sean McGovern]

Hi,

On Thu, Jan 30, 2025 at 1:36 AM Vittorio Giovara
<vittorio.giovara@gmail.com> wrote:
>
> On Wed, Jan 29, 2025 at 9:02 PM Ronald S. Bultje <rsbultje@gmail.com> wrote:
>
> > Hi,
> >
> > On Wed, Jan 29, 2025 at 2:32 PM Kieran Kunhya via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > > It's clear the contribution method is outdated and difficult to
> > > manage. We need to move to GitLab ASAP
> >
> >
> > Yes please.
> >
> > Ronald
> >
>
> +1
> --
> Vittorio
> _______________________________________________

Also yes please -- I'm not particularly attached to GitLab
specifically even though I have my own instance of it running locally.
Any CI/CD tool would be better than this.

-- Sean McGovern
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[Michael Niedermayer]

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

Re: [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@ffmpeg.org> 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.
>
> 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".
>
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[compn]

On Thu, 30 Jan 2025 13:20:19 -0800, Koushik Dutta wrote:

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

is there a way to bridge github with a mailinglist or with gitlab?

theres no reason why we cant have multiple ways to contribute to ffmpeg.

have pull requests send notifications to this mailing list?
https://github.com/settings/notifications

-compn
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> compn
> Sent: Thursday, January 30, 2025 3:53 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] GSoC 2025
> 
> On Thu, 30 Jan 2025 13:20:19 -0800, Koushik Dutta wrote:
> 
> > 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.
> 
> is there a way to bridge github with a mailinglist or with gitlab?
> 
> theres no reason why we cant have multiple ways to contribute to
> ffmpeg.
> 
> have pull requests send notifications to this mailing list?
> https://github.com/settings/notifications
> 
> -compn

There's a working integration which does not only send notifications, it even sends pull requests as patches to the mailing list and mirrors comments from the ML as PR comments. Also handles version updates, performs checks, test build with FATE and requires a successful build+FATE before sending to the ML:

https://github.com/ffstaging/FFmpeg

Explanation: https://github.com/ffstaging/FFmpeg/wiki

sw
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[Vittorio Giovara]

On Thu, Jan 30, 2025 at 10:20 PM Koushik Dutta <koushd@gmail.com> wrote:

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

Because Github is hosted on servers in the US, which are easy to seize for
whatever reason, and controlled by a for-profit corporation, with a past of
unfriendliness towards open source. While lately that company has been
opening up more towards FOSS, there is no guarantee that things won't
change again.
-- 
Vittorio
_______________________________________________
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".

Re: [FFmpeg-devel] GSoC 2025

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 574 bytes --]

On 1/30/2025 6:20 PM, Koushik Dutta wrote:
> 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.
The point is having full control of it, and not host the main repo in 
either Github's or Gitlab's servers. Several devs have good experiences 
with Videolan's Gitlab instance, so us setting up our own is a no brainer.

I also would be fine with Forgejo, but which one is ultimately chosen 
will most likely depend on a vote.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 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".