I do not think there is anything remaining to do. Marking as resolved.

No consensus was achieved on this proposal. MediaWiki releases are currently planned to be explored in WE5.1 of the Wikimedia Foundation 2024-25 Annual Plan.

Thank you, that makes perfect sense. And, we wouldn't want to log out of all services when we log out of Catalyst. I've seen this in many other environments, and I don't know why I was expecting it to be different for this environment. Thanks for the confirmation of the behavior!

Thank you!

I updated the requested redirect URL to "https://catalyst.wmcloud.org/auth".

Excellent question. That won't work. Let me figure out an alternative. Thanks for pointing that out.

The final extension (SimpleBatchUpload) that was found in codesearch to be using the feature being removed by the patch is now no longer using it.

Works perfectly! Thank you!

I was thinking about the redirect URL. If you could please set it to https://catalyst-auth.wmcloud.org, that's probably a better guess about what we will eventually want it to be. I've updated the task description to reflect that.

It can be open to all everyone with a developer account at this point.

idp.wmcloud.org would be fine as well. I was not aware of its existence. The Catalyst prototype is being developed on WMCS, so perhaps that is more appropriate. As long as we can authenticate with a Wikimedia developer account using OpenID Connect and query the groups that the user is a member of, we should be good. That appears to be the case for both IdPs. There appear to be more attributes available from idp.wmcloud.org, but both seem to provide the group information we need initially.

@daniel is there any benefit to leaving this task open at this point? If so, maybe you have more context?

Yes, indeed it is.

In T338208#8906292, @hashar wrote:

Note: the image does not have Xdebug installed so I am not sure from where the v3.0.4 version comes from.

I'm having the same issue on macOS (Ventura 13.4) using MediaWiki Cli. This uses the same versions of PHP and Xdebug reported above.

In T266534#8799738, @Aklapper wrote:

In T266534#8799650, @CCicalese_WMF wrote:

The site currently exists purely for historical purposes as well as for a technical example of potential MediaWiki/phabricator integration.

I don't think that is helpful as I am unable to find the code for this "potential MediaWiki/phabricator integration".

The site currently exists purely for historical purposes as well as for a technical example of potential MediaWiki/phabricator integration. I am declining the task since the Clinic Duty Team is no longer active, so the intent of the task is now moot. But, the site incurs minimal cost and will remain as an example.

Thank you @mforns! The queries since last March have been re-run, and the graph is now updated.

@mforns @Milimetric (since you both have been so kind to help in the past), would you be able to do whatever magic needs to happen to rerun the queries for 2022-03-06 and later to correct the MediaWiki versions in the results? The reportupdater-queries patch has been tested on stat07 and merged. Does anything else need to happen to make it do the right thing going forward? Thanks!

I believe this has been complete for some time.

Documentation and some keycloak commands are added in https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/202.

Great! Exciting! Thanks for including it! Sorry I didn't get the documentation in before the release. I'll try to get it done this weekend.

Where would be the best place to document how to use the new service?

Some notes from the CommTech Hackathon on the prototype implementation of this feature:

In T293323#7909615, @Ladsgroup wrote:

I apologize for pinging here, I honestly could not find a place to make the question as I already tried email, telling my manager, slack, ping in phabricator and I haven't got anything yet. I will make a ticket.

While I definitely agree that the question of volunteer members on the Technical Decision Forum is an important one, I will reiterate that this task is not the place to have that discussion, and a new ticket should be opened as @MarkAHershberger suggested above.

Based upon the discussion on this ticket, the team that has been working on releases has decided to pause and conduct the MediaWiki 1.38 release in the same manner as the MediaWiki 1.37 release, with the MediaWiki Stakeholders' Group assisting Wikimedia Foundation staff. The original plan had been to swap roles and have the MediaWiki Stakeholders' Group take the lead on the MediaWiki 1.38 release with the assistance of Wikimedia Foundation staff, working towards an eventual transition. We hope this will give sufficient time for @Legoktm or others with an interest to submit alternative plans for discussion here. It is hoped that there could be an alternative approach in place for the MediaWiki 1.39 release to relieve the burden of those currently working on MediaWiki releases.

The process of producing MediaWiki third party releases is not a highly resourced project within the Wikimedia Foundation. Much of the effort relies on a group of dedicated staff who do so outside the scope of their normal duties because of their personal commitment. As stated in T293323#7733144, "this has been an area starved of volunteers for many years, and causing burn-out and failing because of it".
The MediaWiki Stakeholders' Group recently incorporated as a non-profit and has been deciding what projects to pursue to benefit the third party MediaWiki community. This seemed like an excellent opportunity for one dedicated group of volunteers to help another dedicated group of volunteers. The idea was that the MediaWiki Stakeholders' Group would take releases on as a service to the MediaWiki third party community -- not as a paid contractor to the Wikimedia Foundation.
I wrote an initial draft of a plan to make this happen that I shared with those two groups of volunteers. I am fortunate to be part of both of those groups. Once I determined that both groups were generally supportive of this approach, as demonstrated through activities during the MediaWiki 1.37 release, I took excerpts from that plan to create this Problem Statement in order to share the idea more broadly and get input. I did already have an approach in mind, albeit a skeletal one that still needed many details fleshed out, and that definitely showed through in this Problem Statement.
This plan was an attempt to take advantage of an opportunity, NOT an effort to exclude any other volunteers. It was NOT intended to lack transparency, but it also didn't focus initially on extensive outreach. That was not the goal of the project.
It is good that this discussion has illuminated that there are other volunteers who have an interest in participating in the release process. This project is still in the "research and prototyping" phase (although it had been moved to the decision record phase, that was premature, as we are still trying to discover and document details of the release process and the related responsibilities), and finding a way to broaden it to other volunteers would be most welcome. @Legoktm, I look forward to seeing your plan, especially as it pertains to resourcing. Pragmatically, what I would like to see is a plan that is implementable and will help relieve the burdens of the current volunteers in the near term. I'm also happy to add anybody who is willing to roll up their sleeves and help with the MediaWIki 1.38 release to our bi-weekly planning meetings.
The MediaWiki Stakeholders' Group will happily step back from this project if there is another group willing to take on MediaWiki releases. They have been willing to help lead the upcoming MediaWiki 1.38 release process, which is why they have requested some additional access, so it would be good if a decision could be made affecting their ability to do so soon. If a decision is made to go another way, that is absolutely fine, as long as it helps relieve the burdens of the current volunteers to the release process.

I do agree completely that question should be answered. That is a question for the Technical Decision Forum. This task represents a Problem Statement submitted to the Technical Decision Forum about managing MediaWiki releases. It is unrelated to the role of volunteers on the Technical Decision Forum.

A team consisting of the Wikimedia Foundation staff that has been producing recent MediaWiki releases and members of the MediaWiki Stakeholders' Group has been meeting biweekly to work through the details of what would be required to transition the releases. A memorandum of understanding (for lack of a better name for the document) is being drafted that documents these details and what responsibilities would be shifted to the MediaWiki Stakeholders' Group (e.g. generating the release files, tracking blockers, and announcing the releases) and what responsibilities would be retained by the Wikimedia Foundation (e.g. providing the infrastructure for releases and certain details of security releases). As Mark mentioned, members of the MediaWiki Stakeholders' Group (specifically, Mark and Markus) assisted in the preparation of the MediaWiki 1.37 release. To make sure no details are being missed, it was decided by the group that Mark and Markus would take the lead in preparing the MediaWiki 1.38 release, with the assistance of the Wikimedia Foundation staff, flipping the responsibilities from the 1.37 release.

In T292903#7657259, @Addshore wrote:

This would mean for a "full" set of shellboxes for local development we would actually need 5 services
Perhaps this is fine, though it doesn't scream amazing developer experience.
...
We could also define an image to build that would have ALL of the needed libraries for development.

And, thank you very much for acting on the request! :-)

In T299367#7651320, @Legoktm wrote:

That policy is for adding or removing people to those groups, not granting those groups permissions.

Sorry to hear about the outage and thanks for troubleshooting!

In T297059#7551446, @Andrew wrote:

Please reopen this ticket when you've deleted the old Stretch VM so that we can reclaim the quota.

Thank you! Will do!

In T297059#7550030, @Andrew wrote:

Thank you for the distro upgrades! For tracking purposes I'd appreciate it if you can create a separate ticket for mwstake and retitle this one to refer to just wikiapiary.

Thank you for the feedback, @WMDE-leszek. I do think that your comments about the problem statement venturing into the solution space are fair. Part of the problem is the questions which must be answered. "What does the future look like if this is achieved?" does not define the problem but rather the world in which the problem has been solved somehow. It is difficult to address that without at least hinting at a solution.

That's great news! Thank you for testing the patch!

This task is no longer a blocker for MediaWiki 1.37. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/731246 fixes some of the problematic behavior and has been backported to the 1.35, 1.36, and 1.37 branches. However, there is still some work to be done on this task as noted by @daniel on the patch:

In T293323#7485761, @freephile wrote:

I have two concerns:

I'm concerned with the 'optics' of WMF stepping away from producing releases for the software to the community of Enterprises and Institutions who use the software for Knowledge Management.

Thank you for the feedback, @Tgr and @cscott. Note that this task is related to the Problem Statement phase of the process. As noted at T293323#7430328, specific solutions will be addressed in the next phase. That being said, your feedback is very valuable in helping to shape the decisions.

@Hogom that's great news! Thank you so much for testing the patch in your environment!

I should note that, if maintenance\populateContentTables.php ran previously and did not complete successfully, it is possible that it will not run again when maintenance\update.php runs, in which case you will need to run maintenance\populateContentTables.php manually after running maintenance\update.php on the target MediaWiki version.