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

[flow gg]

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 <ofiala at 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" <ofiala at 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 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".
>