Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

["Ondřej Fiala" <ofiala@airmail.cc>]

On Wed May 1, 2024 at 1:01 AM CEST, Andrew Sayers wrote:
> On Tue, Apr 30, 2024 at 09:05:05PM +0200, Ondřej Fiala wrote:
> > [...]
>
> IMHO, GitHub have improved that user experience significantly in recent years.
> Yes you're still making a fork and pushing it, but the experience is more like
> click the edit button -> make changes (in an admittedly clunky web editor) ->
> save and push.  The rest is just kinda presented as implementation details.
>
> That's a bit of a nitpick, but the wider point is interesting -
> GitHub etc. are fast-moving targets, so today's friction points become
> tomorrow's selling points, then the next day's lock-in opportunities.
> That makes it hard to compare to a mailing list, which is unlikely to be
> better or worse ten years from now.
That's an interesting point, and I guess it also shows how different
perspectives result in very different conclusions. To me, GitHub being
fast-moving is a negative for the same reason the whole Web tech stack
being fast-moving is.

It means that unless I use the latest Chrome or Firefox or something built on
their engines, I am going to be locked out from participating. Worse, because
contemporary JS technologies are getting increasingly power-hungry, one needs a
relatively recent desktop to be able to use many of these things, which, apart
from leading to needless electronic waste, could be a serious barrier for people
in poorer parts of the world.

Of course, big tech companies intentionally using inefficient software to drive
up sales of new hardware sounds completely like a conspiracy theory... until you
look at the news and read about Microsoft's Windows 11 lacking support for older
hardware without any apparent reason, as people were able to modify the OS to
run on such hardware and it worked just fine. I don't need to remind anyone that
GitHub is owned by Microsoft.

I believe stability and simplicity are virtues, not drawbacks.

> > > [...]
> > I actually agree that the mailing list can be somewhat annoying as well,
> > which is why I like that on SourceHut you can send a patch to their mailing
> > lists without being subscribed and it's standard practice that people Cc you
> > on the replies. I really feel like this should be standard practice;
> > subscribing to the mailing list makes no sense if you only want to send in a
> > single patch, and it increases the effort required by flooding you with emails
> > which aren't relevant to you, as you say.
> >
> > [...]
>
> I haven't properly tried this, and it's an ugly hack if it works at all, but it
> might be possible to support logged-out comments with a web-based trigger.
>
> Triggers are designed to let you e.g. ping a URL on github.com when some
> third-party dependency is updated, and have code on their servers automatically
> pull in that dependency and rebuild your package without manual intervention.
> But you could equally ping "my-web-hook?name=...&comment=..." then have your
> bot turn that into a comment.
I must admit that this is an interesting idea, but unless people can also
contribute that way it's not going to be very useful. And I am afraid that
such "bridging" of email to GitHub would degrade the user experience on both
sides, as I have seen happen in similar cases elsewhere, e.g. with Matrix being
bridged to IRC.

I mean -- if it's decided to switch to GitHub because its code review is
supposedly better, then surely the last thing those people would want is others
sending in their reviews as emails, completely avoiding GitHub's code review
facilities.

> This isn't unique to GitHub - a quick look suggests GitLab can do the same,
> and I wouldn't be surprised if SourceHut can too.  And a self-hosted solution
> could presumably use this as the basis for a general anonymous comment thing.
SourceHut needs no such hacks -- it already accepts comments sent in through
email to its issue tracker, and code review is done directly on mailing lists.
_______________________________________________
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".