On Sat, May 4, 2024 at 3:09 PM Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Sat, May 04, 2024 at 02:04:16PM -0400, Vittorio Giovara wrote:
> > On Sat, May 4, 2024 at 9:06 AM Ondřej Fiala <ofi...@airmail.cc> wrote:
> >
> > > On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote:
> > > > 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 feel it's worth pointing out that SourceHut and mailing list-based
> > > workflows
> > > are becoming popular in some young-dev circles. I am in my twenties for
> > > reference.
> > >
> > > With that said, I did not realize how problematic setting up git
> send-email
> > > can be with some providers when I wrote what you're replying to. The
> > > replies
> > > quite surprised me honestly because when I first set up git
> send-email, I
> > > was using completely average providers and it was all pretty
> effortless,
> > > I just adjusted git's config and it worked perfectly.
> > >
> > > > 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 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.
> > > > I think I should have the right to contribute
> > > Likewise.
> > >
> > > Regarding the part about rejecting patches as attachments, I was
> > > specifically
> > > reacting to Rémi claiming that he can't dictate that people don't use
> them,
> > > which technically he can. I never said it's a good idea, though it
> might
> > > have
> > > sounded that way. Sorry about that.
> > >
> > > As I said multiple times, I feel like contributing over email is a lot
> > > about
> > > having good tooling. For example, the email client I use treats all
> parts
> > > of
> > > a multipart message the same, so it has no issues replying to text
> > > attachments
> > > instead of the message body. As such, there is no difference between
> > > attached
> > > patches and patches in the message body with such a client.
> > >
> >
> > Is it me or has this thread and topic run its course?
> > We understand your preference is email and it is duly noted, the
> > overwhelming majority of the community still seem to prefer
> github/gitlab.
> > Any further discussion at this point looks off topic, there are better
> > venues for discussing the technical merits of email vs github/gitlab.
>
> Is it me or are the top 3 people who objected to gitlab on vaccation,
> banned
> and busy ?
> Maybe we should wait for them to have an oppertunity to comment. One of
> them
> happens to be an experienced gitlab admin
>

If one is banned, then they lose the chance to express their opinion in the
community, it's the whole point of being in a community! You act civil and
your opinions are heard, you troll and you get banned, pretty simple to me.
If we ban people and then wait for them to be unbanned before we take
decisions defeats the whole point of being banned, and instead brings in
pointless filibustering. Maybe they should behave better and not get banned
instead?

For the other two, I think at least one is ok to use command line tools to
my knowledge and that is good enough to at least experiment with a move.
Hopefully we won't stall the move because 3 people vs 238 community members
said so, or do you think we need a vote by the GA on this?

At any rate, my point was that the discussion on github vs email here is
done, nothing can be added to sway either side that wasn't already said.
Since we're starting to see the negative effects of this discussion (our
inability to effectively ban people, making people feel gatekept, and so
on) I'd say it'd be more beneficial to move the agree to disagree
discussion elsewhere, in my opinion.
-- 
Vittorio
_______________________________________________
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".

Reply via email to