Talk:Code stewardship reviews/Feedback solicitation/IRCRecentChanges

Without knowing much about the component, reading the phab ticket, this seems to be a case of a software component that is unmaintained because its essentially feature complete and has none to little bugs. To me this seems like a positive state of affairs, not a negative one.

In comparision, when it was attempted to replace IRC stream with the more modern RCStream, the replacement didn't even last 2 years before having to be re-done as event stream. I think this is a very good example of how new technology often results in lots of wheel-re inventing, where the old technology is very stable.

pre. Replace it with RCStream

What @Bawolff said. I don't wanna speak for operations, but I largely think this service runs itself. The maintenance burden is fairly minimal to MediaWiki itself. Is IRC the best possible format for providing live streams? Absolutely not. But considering it's fairly easy to keep running and there's still quite a few tools that use it, I don't see a pressing reason to end it.

I'm curious what actual problems we're having here? In some pretty naive searching on Phabricator, I'm not seeing any huge issues with it.

For the record, Faidon was the one who proposed this as he sees it as a maintenance burden for them (notably the forward-porting when an OS version EOL's). So calling it unmaintained is not accurate, it's more "maintained at the last minute in unhealthy ways".

Fair enough, upgrades of the IRC daemon and OS can be a pain. I certainly understand that--but I meant more in the "constantly having to futz with it to keep it online" which I haven't seen evidence of.

So yes: a non-zero maintenance burden, but not a huge one?

Something like that; I'd let @Faidon Liambotis (WMF)answer more since he's closer to the issue.

Many countervandalism and IRC bots depends on this as @😂 (will the mention arrive?) says. While there might be better alternatives, there are currently a lot of tools that still depends on this. Moreover if the people who know about MediaWiki agree that little coding has happened because the feature is very stable and works finely then I don't see a need to end it. Thanks.

I think ticket T134271 on Phabricator gives a few reasons on why this project is on the list. Basically it has to do with the fact its running ircd-ratbox, which is fairly old at this point. It's not maintained well and lacking a few features

T134271 and the maintenance and security repercussions of the existing software stack are indeed part of it. Reliability, i.e. the fact that important functions on our sites (such as countervandalism) all rely on a single server (in a single datacenter) being up, is also another part of it. Us scheduling maintenance windows for simple kernel upgrades/reboots is unacceptable, as is scrambling to respond when that server inevitably goes down at some point. I detailed some of that on T185319, and happy to respond there if I can elaborate more (BTW, splitting the conversation between here and Phab seems odd -- I only found this thread since someone mentioned my name!).

Alsom The fact that RCStream was short-lived and IRC stayed around doesn't mean that IRC was better designed than RCStream, but rather that the service's user base isn't very responsive to upstream changes and/or that we didn't have a very good communication/deprecation plan, or executed that right. As I proposed on the task, IMHO the two ways forward is either accepting that our user base is slow moving and building something new that's wire protocol compatible, or deprecate that service and fund a project to help users migrate. Or a combination of both :)

"(BTW, splitting the conversation between here and Phab seems odd -- I only found this thread since someone mentioned my name!)."

This is due to us wanting the widest possible feedback; not everyone who has a stake in something being reviewed is a user of Phabricator. I should cross-link in the Phab tasks, though.

There may be some good points around ircd patching, but I think my comments with regards to the resiliency problem stand - there is nothing limiting the current system to only one server.

There's always a cost to maintaining things even if not obvious. As someone who supposedly helps maintain the Modern skin, I can attest that extensions/skins I don't understand but am maintaining cause lots of additional and IMO unnecessary stress, because of the possibility that something can go wrong.

What would happen if there was a big difficult bug that appeared in the IRCRecentChanges extension? Who would fix the issue in this case? What would the process be? Would the train be halted? Would it be okay to disable the extension temporarily until the problem was resolved? I think it would be interesting to consider these types of questions when thinking about things that on the surface have low maintenance needs.

The MediaWiki part is in Core, it's not an extension. For Wikimedia I think the rest is a separate service and customised IRCd.

It would not be acceptable to disable it for more than a brief maintenance period.

@Krenair I realize that this service is now critical to the projects, which is why it's going through this process in the first place. If it'd be simple, I'd just turn it off with a simple notice instead :)

(I don't agree with your resilience assesment or maintainability of the current setup, for what it's worth)

@Faidon Liambotis (WMF) I know you know that, I was talking to @Jdlrobson

I would encourage you to provide your disagreements but the reviews just closed.

https://lists.wikimedia.org/pipermail/wikitech-l/2018-February/089493.html