- Verify extension is working for folks
- Backport to REL1_27 and REL1_28
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Deskana | T75616 Tracking: API/backend issues blocking Wikipedia app development | |||
| Resolved | Anomie | T32788 Allow triggering of user password reset email via the API | |||
| Open | None | T90925 General authentication improvements for MediaWiki | |||
| Resolved | Anomie | T48179 Allow a challenge stage during authentication | |||
| Open | None | T5709 Refactoring to make external authentication and identity systems easier | |||
| Resolved | Tgr | T43201 UserLoadFromSession considered evil | |||
| Resolved | Anomie | T67493 Session is started by EditAction (problem for extensions using UserLoadFromSession hook) | |||
| Open | Feature | None | T55156 Provide option to force a login session to end within a certain time | ||
| Open | None | T89459 Modernize MediaWiki authentication system (AuthManager) | |||
| Open | None | T110291 Update all extensions to use AuthManager | |||
| Resolved | Enst80 | T110292 Update Auth_remoteuser to use AuthManager | |||
| Resolved | Enst80 | T163097 Backport Auth_remoteuser to REL1_27 and REL1_28 |
Event Timeline
Comment Actions
Hi @GICodeWarrior. Please associate at least one project with this task to allow others to find this task when searching in the corresponding project(s). Thanks!
Comment Actions
Hi,
i'm all for backporting to these two branches, because:
- Both branches pointing to a commit which doesn't work with the related MediaWiki 1.27 or 1.28 versions.
- MediWiki extension ExtensionDistributor (or its according page Special:ExtensionDistributor) selects tarballs by branch name, which do not give a working version (because of 1).
- There's no extra work for backporting to REL1_28 because it would be a simple fast-forward-merge.
- There's little work for backporting to REL1_27 because this branch is one commit off from the according master branch commit and it touches the .gitreview file only, which isn't changed by the current commit for v2.0.0. So the (backport/cherry-pick) merge should be simple.
- Especially MediaWiki 1.27 is supposed to be LTS (long term support). An extension should follow this if applicable.
Regarding verification of installations
I've testet it with vagrant installations:
I'm running it on production environment:
- 1.27.0 with a small user base.
- 1.27.1 with several 100s of users on a daily basis.
Comment Actions
Hi all,
i've uploaded a backport merge for the REL1_27 branch regarding this topic T163097.
For REL1_28 i can't do anything, because it is a fast-forward merge which gets declined from gerrit due to "no new changes" for review.
There are two options for REL1_28:
- @GICodeWarrior has to force push the fast-forward merge of REL1_28 without reviewing it (because he's the only one who can do that due to access permissions)
- i create a separate merge object for REL1_28 so that it is no fast-forward merge anymore (but then it would not be the same commit object as for T110292 in master).
Your opinions?
Comment Actions
Hi again,
i opt for the second solution, because it seems easier to understand when the REL1_28 branched off from master. Therefore i uploaded the according backport merge.
You can see [[ https://gerrit.wikimedia.org/r/#/q/topic:T163097+(status:open+OR+status:merged) | both backports now in this list for T163097 ]].
If you opt for the first solution (fast-forward), then just decline this Patch Set for REL1_28.