[FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft

[Paul B Mahol]

On Tue, Apr 9, 2024 at 10:57 PM Romain Beauxis <romain.beauxis at gmail.com>
wrote:

> [Apologies for continuing the conversation, Rémi]
>
> Le mar. 9 avr. 2024 à 14:05, Tomas Härdin <git at haerdin.se> a écrit :
>
> > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel <
> > > ffmpeg-devel at ffmpeg.org> wrote:
> > >
> > > > Hi Raphael,
> > > >
> > > > I was the author of the tweet and I gave a short talk about this
> > > > topic at
> > > > Demuxed at a video conference last year:
> > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s
> > > >
> > > > That said this is a community project and it would be best to
> > > > continue the
> > > > discussion on this mailing list unless agreed otherwise.
> > > >
> > >
> > > Thank you for sharing your talk. It's indeed unfortunate that large
> > > companies are not more generous with the projects they depend on
> > > _heavily_
> > >
> > > I would like to offer a constructive feedback really not intended as
> > > trolling. I believe that supporting a more modern development
> > > workflow such
> > > as the GitHub PR or gitlab MR would go very long way in helping
> > > onboarding
> > > new developers.
> >
> > Considering which company owns GitHub and which company was the target
> > of Kieran's criticism, this seems ill-adviced
> >
>
> Would you mind explaining what you mean exactly? I want to respond but I'm
> not sure if I fully understand your point here.
>
>
Kieran's criticism is trolling, as Kieran and rest of FFmpeg devs use
regularly and passionately Various Big Corpo products all the time.

Kieran's criticism is unfounded one. As I, originally 'volunteered' in that
now 'famous' ticket about Certain Big Corpo bug report and kindly replied
in friendly manner to bug reporter and give reporter free support, me still
see no issues in that mine action.

I strictly do make difference between collective and single specific person.


>
> > Also as someone who had to maintain a Gitlab instance at uni for a
> > couple of years, I agree with Rémi's points
> >
>
> My initial contribution was motivated by the argument presented in the
> original talk that bringing new blood is critical to the survival of the
> project.
>

Projects go and die, and new ones rise up, all the time.


>
> If so, then I do believe that there must be a compromise to be made between
> being easier to join for new developers and changing the existing workflow.
> I'm also aware that changing the existing workflow has been discussed
> before.
>
> I don't think that media is not cool anymore, as argued in the talk. I see
> a _lot_ of interested developers in my other projects and all over the open
> source landscape. That's why I believe that it's also important to consider
> other reasons than the talk's argument.
>
> Being someone actually trying to contribute, with years of developers
> experience and involvement in other communities, I was thinking that I may
> be able to bring in more new context to the topic.
>
> If there's interest in continuing the discussion, could you or Rémi be
> willing to explain what kind of burden gitlab would add?
>

Infrastructure maintenance, no volunteers for gitlab repo admin.
Extra steps to setup account and X-factor authentication.


>
> Also, Rémi said this would make it harder to join the project, in which way
> exactly?
>
> Otherwise, I'm happy to let this die and return to trying to get my patch
> committed.. 🙂
>
> Thanks,
> -- Romain
> _______________________________________________
> 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".
>