Freenode and libera.chat
Andrey Kurilin
andr.kurilin at gmail.com
Fri May 21 17:28:30 UTC 2021
пт, 21 мая 2021 г. в 18:48, Clark Boylan <cboylan at sapwetik.org>:
> On Fri, May 21, 2021, at 7:28 AM, Andrey Kurilin wrote:
> >
> >
> > пт, 21 мая 2021 г. в 17:17, Jeremy Stanley <fungi at yuggoth.org>:
> > > On 2021-05-21 16:30:40 +0300 (+0300), Andrey Kurilin wrote:
> > > [...]
> > > > Why everyone points to third-party solutions for those who don't
> > > > like IRC? Why the modern chat-platform can be used as a main
> > > > solution and those who want IRC should look for third-party
> > > > bridges to make it work in the good old way?
> > > [...]
> > >
> > > It's all a matter of perspective, and you're paying attention to how
> > > it's phrased by people who are already using IRC (the bulk of our
> > > current community). You could just as easily phrase it as "some
> > > projects are moving to Matrix, but taking advantage of the available
> > > Matrix/IRC bridge so that users of the old IRC channels aren't left
> > > behind." Technically the solution is the same one as "let's
> > > recommend a Matrix/IRC bridge to anyone who wants to talk with
> > > people on IRC without using IRC." The main difference is in how it's
> > > documented and communicated.
> > > --
> > > Jeremy Stanley
> >
> > > It's all a matter of perspective
> >
> > It is True without context.
> > I may be wrong, but I do not remember any big change in OpenStack
> > community (maybe only the 4 opens and nova-net -> neutron, but it's
> > earlier days). If something was used/developed/decided 10 years ago, we
> > will live with that forever.
>
> I feel like a big part of this is lots of people have very grand ideas,
> but no time and willingness to invest in them. We have done a number of
> large changes since nova-net -> neutron including an entire Zuul v3
> rewrite,
yes, Zuul is another thing that occurred to me as soon as I sent an email,
but it was late to change anything.
> the massive Gerrit upgrade last year, deployment and use of
> global-requirements and later constraints and their later modifications,
> fully automated most details of the OpenStack release process, and so on. I
> am sure there are many more, but I've got a bias due to the things I'm
> exposed to.
>
Most of the listed things are just required things to do. It doesn't
simplify them or decreases greatness.
> A key detail with all of those is they found champions who worked through
> them, got necessary consensus and implemented the changes.
>
Sure thing. I do not want to hurt anyone, I know that there are a lot of
people in our community that implemented a bunch of great, necessary and
important tasks. And thanks to everyone for that.
The problem is in the over-complexity of doing such changes.
> > That is why I read all suggestions of using matrix as "if you don't
> > like the chosen way, we are very sorry, but please find a way to leave
> > with it. this is the way." :)
>
> I would characterize it more as "if you don't like the chosen way and have
> no willingness to help change things then it is unlikely that anything will
> change". From my (again biased) perspective it seems more and more that
> when people show up with ideas there is an assumption that someone else
> (often me) will simply whip something together for them and when that
> doesn't happen it is because the idea is rejected upfront rather than
> needing investment.
>
I understand what you are talking about, but only one or two emails
mentioned the complexity of implementation and load of infra-team. Most
emails of the topic cover only theoretical point of view "whether we want
one or another solution".
> Matrix as an IRC alternative has been brought up a number of times in the
> past, but it has always lacked someone or a group of someones that are able
> to PoC it, determine what would be necessary to switch, make the necessary
> changes, then guide the project through a transition if the decision is
> made to move. This isn't as simple as registering on the service and
> joining channels either. You'll need ops/moderators, channel management,
> updates to existing bots that people want to keep, privacy policies may
> need to be considered, etc. The suggestion to use the matrix IRC bridge is
> a good way to simplify all of this though.
>
> For this reason I think it would be useful to shift the conversation back
> to whether or not Freenode is viable going forward. If the consensus for
> that is "yes" then we start a completely separate conversation on whether
> or not we want to move to an alternative protocol and take our time. If the
> answer is "no" then it is probably best to make an "easy" move using
> consistent tooling for now, then start a conversation on whether or not a
> move to another set of tools longer term makes sense separately.
>
I dislike questions with binary answers. Such questions are too limited.
For example, if you ask me for a binary answer for the topic - I would just
ignore answering because I use IRC rarely and only for openstack purpose.
Should we move from Freenode to another IRC network? I don't care much,
that is my answer...
But again all of these options require effort and effort requires humans.
> Let's try to address the immediate problem first without conflating issues
> which only causes confusion and will make it more difficult to solve the
> problem in front of us. Then once that is behind us, bring up the other
> discussions in a productive manner (this includes acknowledging the other
> side might have an opinion worth listening to and that the other side
> doesn't make choices simply because they have grown long beards).
>
> Note: I've addressed some of the other ideas in the larger thread in this
> response, but they aren't necessarily the views of those I am directly
> responding to.
>
> >
> > --
> > Best regards,
> > Andrey Kurilin.
>
>
--
Best regards,
Andrey Kurilin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210521/f2a6283f/attachment.html>
More information about the openstack-discuss
mailing list