Page MenuHomePhabricator

Backport Auth_remoteuser to REL1_27 and REL1_28
Closed, ResolvedPublic


  1. Verify extension is working for folks
  2. Backport to REL1_27 and REL1_28

Event Timeline

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!

i'm all for backporting to these two branches, because:

  1. Both branches pointing to a commit which doesn't work with the related MediaWiki 1.27 or 1.28 versions.
  2. MediWiki extension ExtensionDistributor (or its according page Special:ExtensionDistributor) selects tarballs by branch name, which do not give a working version (because of 1).
  3. There's no extra work for backporting to REL1_28 because it would be a simple fast-forward-merge.
  4. 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.
  5. 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:

  • 1.27.1 (36b636d) 19:26, 11. Jan. 2017
  • 1.28.0 (65c2a1a) 20:18, 8. Feb. 2017

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.

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?

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 [[ | 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.

Enst80 claimed this task.