I saw about comparing emails and gitlab/hub .., I did not comprehensively understand their advantages and disadvantages, but I want to say that I support it to change to gitlab/hub
Simple reason: If you need to use git-send-email, I may not be able to submit any code If you do not need to use git-send-email, it is troublesome for the reviewer and the contributor In detail: I have tried git-send-email, but it failed. You can say that I am stupid, but I would say that this is because of various reasons such as my area and the network. It is really not what I can solve. Maybe I will spend a lot of energy trying it in the future, but this is because I have submitted thousands of lines of code. I don't want to give up. If it is from the beginning, it will cause abandonment. Maybe I am younger here in FFMPEG. I have a lot of good young people around me. They all use github/lab by default, and there will be the same problem as me, resulting in abandonment. I don't really care about the quality between these tools. I think people are important. I only want to use it, and I can facilitate the real reviewer of Review. I don't know if I can say my personal feelings here, but I will say: I feel despised by this passage, which makes me uncomfortable. If you are a reviewer, maybe I have no chance to contribute, but anyway, I have made some contributions. > How can anyne use git, but not git send-email? Any develop email provider HAS Support for External Clients Over SMTP. And I Believe You * Can * Actually Dictate that people doon't attach patches - if you have control over the Mailing list software, you can set up a filter that rejects such emails And auto-replies with instructions on how to send them properly. I think I should have the right to contribute Ondřej Fiala <ofi...@airmail.cc> 于2024年5月2日周四 22:25写道： > On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote: > > Le 30 avril 2024 22:15:10 GMT+03:00, "Ondřej Fiala" <ofi...@airmail.cc> > a écrit : > > >On Tue Apr 30, 2024 at 9:06 PM CEST, Hendrik Leppkes wrote: > > >> I will take the replacement instead, thanks. Email is archaic. The > > >> entire point is to get away from email, not dress it up. > > >> SourceHut usage would likely make me even less interested then today. > > >> > > >> - Hendrik > > >I guess that depends on how (and with what) you use it. Using it with > > >Gmail UI for example is obviously not a great idea. No idea whether you > > >do, but if you do, you should be upset at Gmail, not email. > > > > 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. Many email > clients > have support for threading, and unlike GitHub allow threads of arbitrary > depth. 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. > > > 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. And I believe you *can* > actually > dictate that people don't attach patches -- if you have control over the > mailing list software, you can set up a filter that rejects such emails > and auto-replies with instructions on how to send them properly. > > > >But you did not answer my question: which specific code review features > > >are you missing? > > > > Proper threaded reviews with state tracking, ability to collapse and > expand > > context and files, and proper listing of open MR (*not* like patchwork). > I can sort of understand everything except the last one. What is "a proper > listing of open MR" supposed to mean...? (I know what a merge request is, > of course, but I don't get how the way GitLab lists them is supposedly > superior to SourceHut's list of patches.) > _______________________________________________ > 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".
