Tue, Jun 21
Tue, Jun 14
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 14 2022
Jan 13 2022
Jan 6 2022
Jan 3 2022
Dec 24 2021
Dec 21 2021
Dec 18 2021
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
@Hogom said in the task description:
Oct 20 2021
Yes, download the patch file from the bottom of the dialog and then apply it using the patch command.
That would be great! If you click on each of the patch links above, you can click on the 3 dot menu at the top right and select Download patch.
Great, thank you! So, I am declining this task. If you want to pursue the issue with icon placement for the tweeki skin, please feel free to open a new task. More information about why the current CSS is problematic for tweeki would be helpful, especially if there is a suggested fix that won't break vector or chameleon.
Oct 19 2021
I'm not convinced that this is a CommentStreams bug, as CommentStreams doesn't show up in the stack trace at all. I tried to reproduce locally. I installed SMW 3.2.3 with MediaWiki 1.35.4 and CommentStreams 6.3. I added a comment and a reply. I then upgraded to CommentStreams 7.0. All works fine. Is the problem repeatable for you?
The new library is great! It fixes the prompt issues I was having completely.