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

Romain Beauxis romain.beauxis at gmail.com
Wed Apr 10 04:43:54 EEST 2024


Le mar. 9 avr. 2024 à 18:46, Paul B Mahol <onemda at gmail.com> a écrit :

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


Thanks for the clarification, that's a level of nuance I did not grasp.

>
> > > 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.
>
>
You have a little bit of a bias issue here I believe. :-)

If you restrict the contributors only to people who can do git send-email
and irc then, of course, you won't find many volunteers to maintain a
gitlab repo. And, of course, the majority of the people voicing their
opinion will be in favor of what they're already familiar with.

There's always a learning curve to adopting new tools. Matter of fact, I'm
old enough to remember myself complaining about git when it was taking over
SVN.. 🙂


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


More information about the ffmpeg-devel mailing list