User Details
- User Since
- Jul 27 2017, 2:31 AM (371 w, 1 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- CCicalese (WMF) [ Global Accounts ]
Apr 27 2024
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.
Feb 12 2024
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!
Feb 6 2024
Dec 16 2023
Vielen Dank!
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.
Dec 7 2023
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.
Nov 13 2023
Works perfectly! Thank you!
Nov 10 2023
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.
Nov 9 2023
Nov 7 2023
Oct 18 2023
@daniel is there any benefit to leaving this task open at this point? If so, maybe you have more context?
Oct 15 2023
Aug 10 2023
Jul 3 2023
Jun 17 2023
Jun 9 2023
Yes, indeed it is.
Jun 8 2023
Jun 7 2023
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.
May 14 2023
May 12 2023
Apr 24 2023
Apr 23 2023
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.
Feb 23 2023
Jan 23 2023
Thank you @mforns! The queries since last March have been re-run, and the graph is now updated.
Jan 17 2023
@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!
Jan 12 2023
Jan 11 2023
Nov 23 2022
Aug 22 2022
I believe this has been complete for some time.
Jun 14 2022
Documentation and some keycloak commands are added in https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/202.
May 25 2022
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.
May 23 2022
Where would be the best place to document how to use the new service?
May 19 2022
Some notes from the CommTech Hackathon on the prototype implementation of this feature:
May 6 2022
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.
May 5 2022
Apr 19 2022
Apr 1 2022
Mar 7 2022
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.
Feb 27 2022
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.
Feb 21 2022
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.
Jan 27 2022
Jan 26 2022
And, thank you very much for acting on the request! :-)
Jan 24 2022
Sorry to hear about the outage and thanks for troubleshooting!
Jan 21 2022
Jan 17 2022
Jan 13 2022
Dec 10 2021
Thank you! Will do!
Dec 6 2021
Dec 5 2021
Nov 18 2021
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.
Nov 9 2021
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:
Nov 5 2021
Nov 3 2021
Nov 2 2021
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.
Oct 29 2021
@Hogom that's great news! Thank you so much for testing the patch in your environment!
Oct 28 2021
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.
@Hogom, you will need to patch the version of MediaWiki that you are trying to update *to* (in this case, MediaWiki 1.35), not the version you are trying to update *from*. You will then run maintenance/update.php, which will run maintenance/populateContentTables.php.
@Hogom, thank you for trying to apply the patch. It looks like you are not running the latest version of MW 1.33, so it is missing at least one other patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/542232). It may not be fruitful to continue trying to patch that version.
@Hogom, sorry the patch didn't apply cleanly to MW 1.33. I created the different versions of the patch above that could be tested with the respective MediaWiki version.
Oct 26 2021
Oct 25 2021
Vielen Dank!