On 2 May 2024, at 21:32, Ondřej Fiala wrote:
> On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote: >> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit : >>> On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote: >>>> I don't use Gmail, and using email for review still sucks. No matter how >>>> you slice it, email was not meant for threaded code reviews. >>> >>> Email was not meant for a lot of what it's used for today. >> >> And Gitlab and Github are meant for what they are used. >> That's the whole point. > This argument can actually go in both directions since the Web and web > browsers weren't meant for performing code review either. If you remember, > the Web was originally intended for sharing *documents*, which a MR page > on GitLab definitely isn't. > > IMHO, the fact that something was intended for some use case does not imply > that it's actually good for that use case. My point was that what it was > meant for does not matter, what's important is if and how well it works > for that use case. > >>> and unlike GitHub allow threads of arbitrary depth. >> >> I don't care because *GitHub* is out of the race for other reasons anyway. I >> have never had a situation whence *Gitlab* refused to add more comments to a >> thread. > I said *depth*, not *length*. AFAIK GitLab can't create message threads like: > > message > |- reply > | |- reply > | | '- reply > | '- reply > '- reply > '- reply > >>> Using such a client with commands for moving between >>> messages in a a thread etc. makes threaded code review over email quite >>> usably in my opinion. >> >> So how do I ask my mail agent to pull more existing code for context? Or to >> get back to the code that started a thread? > Why would you do that in a mail client? You have your personal copy of the > repo, so you can just import the patch by piping it to `git am` and then > use any of the wide array of git-supporting *specialized code review software* > to look at the changes! How do I see the review comments that way? > > Of course, the quality of your toolings matters a lot. If your email client > can't pipe a bunch of emails to a shell command, it's not fit for being used > to review git patches. On the other hand, if you possess just some basic shell > scripting skills, you can make it do pretty cool things. So I first have to get proficient in some shell scripting gymnastics (and also switch to a completely different terminal-based mail client) so I can do proper reviews? Thats incredibly gatekeeping. > > Since you felt that there is no way to see additional context, I put together > a quick demo[1] showing how easily you can review all files affected by a > patch > and look at *all* the context. Of course, you could do a bunch of other > things to > adjust the email-based workflow as desired. And don't forget this is just a > demo; > I am sure you could come up with something better. > > [1] https://paste.c-net.org/HansenWeekends That seems to download some binary file? I have no idea what it is supposed to be. > > It's just sway, aerc, and a fuzzy picker combined. The command "changes" is > just: > changes() { > while p="$(git diff --name-only origin/master | pick)"; do > git diff -U9999999 origin/master "$p" > done > } > >>>> Also while I can use git-send-email, not everyone can. And patches as >>>> attachments are simply awful. Unfortunately I can't dictate that people >>>> don't send patches that way. >>> >>> How can anyone use git, but not git send-email? Any decent email provider >>> has support for external clients over SMTP. >> >> Simply put: no, that is simply not true. >> >> Not everybody can pick a decent email provider with outbound SMTP and a good >> reputation. Also not everybody gets to pick their mail agent or their ISP. >> >> You are just being unwittingly elistist here. > I must admit I did not realize how bad some email/internet providers can be > when writing this, as I have a fairly average setup and never ran into such > issues. > > But the problem with accessibility is not aleviated by switching away from > email, since those forges aren't universally accessible either. I remember how > I used to run Pale Moon like 2 years ago. In case you don't know, it's a > Firefox > fork maintained by a small team. GitHub didn't run on it. Oh, sorry, you don't > care about GitHub. But they share the same desig -- hugely complex "web app" > that only runs on latest version of major browsers. Everyone else is excluded. > When I wanted to contribute to a project I really cared about, I had to > download > mainline Firefox and do it over that. If I cared even a bit less about it, I > wouldn't bother. > > So how is that any different? How is it different to download a well maintained recent software and open a website, in comparison to learn how to setup a (complex) combination of tools just to be able to easily contribute? > > I think the solution to the email issues you mentioned could be to have the > ability to upload patches through the SourceHut UI directly. Since SourceHut > is still not feature-finished AFAIK, it could actually be added if there was > enough interest. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
