Well maybed we could use SyntaxHighlight for Pygments. And use SyntaxHighlight_GeSHi for users that just want a php based highlighter.

In T103614#1428252, @Paladox wrote:

Well maybed we could use SyntaxHighlight for Pygments. And use SyntaxHighlight_GeSHi for users that just want a php based highlighter.

Why? What does it matter to the end-user what language it is written in? Are there any problems with the new version?

Well some users may just want a php based highlighter which geshi is and Pygments was moved into the extension with the name of the extension being called GeSHi so it should be called Pygments.

Details to create the repo are

Type = mediawiki extension

Name = SyntaxHighlight

Maintainer = Wikimedia

Author = not sure.

Change 222984 abandoned by Krinkle:
Renamed Geshi to Pygments

Reason:
Closing as we won't be using the name "SyntaxHighlight_Pygments".

https://gerrit.wikimedia.org/r/222984

@QChris what I mean by renaming is moving out the new syntax highlighter package from geshi and reverting geshi back to what it previous was geshi.

@Paladox There is no reason to maintain Geshi. There is no interest. It's no longer maintained or useful to us. Unless you indicate a clear reason for what purpose there is in using Geshi, that argument is invalid.

However I agree using Geshi in the name is confusing, which is why I already told you that we'll be renaming the extension. Just not right now.

Oh ok.

GeSHi-backed SyntaxHighlight could still be useful to any sad third-party users who are stuck on shared hosting or some such and can't shell out to call Pygments. Not sure if there are any such users who need syntax highlighting, but making such a thing available somewhere other than depths of Git history costs us basically nothing (one more repository, a few words of documentation at https://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi with a link to older version of that page) and might help someone.

So, it seems that the actions required are, in order:

• Delete unused mediawiki/extensions/SyntaxHighlight_Pygments repository
• Copy mediawiki/extensions/SyntaxHighlight_GeSHi repository to mediawiki/extensions/SyntaxHighlight
• Update WMF configuration so that sites don't explode later
• Move https://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi to https://www.mediawiki.org/wiki/Extension:SyntaxHighlight and update it to point to new repository
• Rewind master of mediawiki/extensions/SyntaxHighlight_GeSHi to f3476de0158e464db442213d6731b691a2dd8af1 (the last GeSHi-backed revision)
• Document at https://www.mediawiki.org/wiki/Extension:SyntaxHighlight that a GeSHi-backed old version (not requiring Pygments, Composer, or non-crippled PHP) is available, linking to the old documentation present at https://www.mediawiki.org/w/index.php?title=Extension:SyntaxHighlight_GeSHi&oldid=1678704 (the last revision documenting GeSHi-backed version)

+1 to @matmarex

Me to +1 to @matmerex. Where do I request that the repo be created.

Let's not rush, there are some patched for SyntaxHighlight open (https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/SyntaxHighlight_GeSHi+is:open,n,z), it would be nice to resolve them before we rename (and thus force authors to resubmit their patches). If we agree this makes sense, and after the current dust settles (we're still doing some follow-ups to the Pygments migration), then we can probably work with Chad or QChris to shuffle the repositories and update docs and stuff. In a week or two, let's say.

Well we could set up the repo then copy the files from geshi repo to new one then reviewe the code for other users who have uploaded to geshi and ask people to upload to the new repo after creating it.

You can cherry pick from another repo and just git-review. I actually had a hacky script for migrating patches between repo (because I had tens to migrate from the apache-config to puppet at one time).

But still, easier if we just get them migrated first... @Esanders and @Krenair can you guys co-review each others VE patches to the extension to get them off the outstanding list? Or else, find someone else to review them :)

Also, when we are thinking about the name... There is https://www.mediawiki.org/wiki/Extension:SyntaxHighlighter - It's not on gerrit, but github, but it'd be yet another similarly named extension...

In T103614#1430147, @matmarex wrote:

• Document at https://www.mediawiki.org/wiki/Extension:SyntaxHighlight that a GeSHi-backed old version (not requiring Pygments, Composer, or non-crippled PHP) is available, linking to the old documentation present at https://www.mediawiki.org/w/index.php?title=Extension:SyntaxHighlight_GeSHi&oldid=1678704 (the last revision documenting GeSHi-backed version)

If it's meant to be an extension on its own, then it should have a real documentation page, shouldn't it?

I have requested here https://www.mediawiki.org/wiki/Git/New_repositories/Requests so that it would be created so when ever were ready we can move over to that repo and revert geshi back to to before the change.

In T103614#1448074, @Paladox wrote:

I have requested here https://www.mediawiki.org/wiki/Git/New_repositories/Requests so that it would be created so when ever were ready we can move over.

There's no need for a new repo request. When we're ready this will be dealt with all-at-once.

Hijacking repos seems bad and bad practise. Just create a new one with the new lib and archive the old one, keeping the REL branches for third party.
That makes it clear with the history in git, open patch sets in gerrit and all the open or closed tasks in Phabricator/Bugzilla.

So +1 to @matmarex

Hi ok we arnt hijacking any repo I was only suggesting to use it since it was created for it but later decided to use geshi extension. But a request for a new repo is waiting to be created but for now reviewers are currently reviewing patches for follow up then once all those patches are approved then the repo can be moved.

Change 222986 abandoned by Jforrester:
Re added GeSHi back

https://gerrit.wikimedia.org/r/222986

Hi is there an update on the status because it has been two weeks. have most of the follow up patches been approved or still waiting.

We should start renanming the extension since most bugs have been fixed. Since this should be under a new name.

Its been a month since we last discussed this. The name in the extension is called SyntaxHighlight which is confussing because the name of the extension is SyntaxHighligh_GeSHi

Change 222984 restored by Paladox:
Renamed Geshi to Pygments

https://gerrit.wikimedia.org/r/222984

Change 222984 abandoned by Paladox:
Renamed Geshi to Pygments

https://gerrit.wikimedia.org/r/222984

Hi any changes. I think the backlog is cleared now.

I agree, I think now's a good time to go forward. @QChris, can you sanity-check the steps at T103614#1430147 and do the first Gerrit part?

Ok I have requested at the gerrit page for requesting new repos I linked to this task so they know what they do I described reaming the repo from this name to the new one and then reverting this repo back to geshi.

Wait, which is the plan now? One extension or two? If two, why? If two, which one goes in the bundle? If two…

Well for one not all servers run python. It dosent work for me whereas using geshi did. And plus the extension name is confusing because it now uses a different package to its name.

The plan is T103614#1430147.

• Remove unused repo SyntaxHighlight_Pygments.
• Rename SyntaxHighlight_GeSHi to SyntaxHighlight.
• Leave SyntaxHighlight_GeSHi rewound to previous GeSHi-state; open for new maintainers.

However priority are elsewhere now. This should not be acted on independently until we can take it all the way. Please refrain from any preparation work as it would conflict. When we're ready, the assigned person can do it all at once.

In T103614#1606274, @matmarex wrote:

I agree, I think now's a good time to go forward. @QChris, can you sanity-check the steps at T103614#1430147

Looks good. Only one slight adaption:
Gerrit does not allow to copy or move repos. All we can do is delete repos and re-create them under a new name and push git histories. But deleting a repo kills all past code reviews. I guess we would not want that for this repo.

So instead of

• Copy mediawiki/extensions/SyntaxHighlight_GeSHi repository to mediawiki/extensions/SyntaxHighlight
• [...]
• Rewind master of mediawiki/extensions/SyntaxHighlight_GeSHi to f3476de0158e464db442213d6731b691a2dd8af1 (the last GeSHi-backed revision)

I'd suggest doing

• Push refs of mediawiki/extensions/SyntaxHighlight_GeSHi to mediawiki/extensions/SyntaxHighlight
• [...]
• Do a single revert commit on mediawiki/extensions/SyntaxHighlight_GeSHi that brings the repo to a state that is equivalent to f3476de0158e464db442213d6731b691a2dd8af1 (the last GeSHi-backed revision).

That way, all the code reviews are retained and the repos hold the needed code.

and do the first Gerrit part?

Not doing the Gerrit part, due to @Krinkle's above comment (T103614#1632101)

In T103614#1632101, @Krinkle wrote:

• Leave SyntaxHighlight_GeSHi rewound to previous GeSHi-state; open for new maintainers.

Why bother doing this? It's uncool to leave dead code lying around in a place it was formerly maintained and casually-familiar people might not recognise.

Well for one thing for users that want to use geshi. And second not always will the new package work. Doesn't work for me.

Hi do you know when would we be ready to do the migration.

Change 249058 had a related patch set uploaded (by Krinkle):
Archive repository

https://gerrit.wikimedia.org/r/249058

Change 249058 merged by Krinkle:
Archive repository

https://gerrit.wikimedia.org/r/249058

What about having both geshi and Pygments in this repo. And add a new setting maybe called SyntaxHighlighterPackage allow users to choose either geshi if they doint have Python installed or Pygments if they do. It will make everything easier and easier to maintain. Since it will be in one repo the name SyntaxHighlight name can be used since that name suggests that there are other packages such as Pygments or geshi.

In T103614#1832865, @Paladox wrote:

It will make everything easier and easier to maintain.

I don't think so. And Geshi is dead, as been written before in this thread.

Yes but what about users that doint have or doint want to use the python one.

In T103614#1833079, @Paladox wrote:

Yes but what about users that doint have or doint want to use the python one.

They either won't use SyntaxHighlighting or have to start maintaining Geshi.

Maybe instead of having two separate extensions we just have one that does both. We should include a setting that either enables geshi or pygments. Since some users doint have python installed or doint want to use it but want to use something that is built to using php.

In T103614#2006982, @Paladox wrote:

Maybe instead of having two separate extensions we just have one that does both.

If there is just one, it would be a feature added to the "SyntaxHighlight" extension, in which case that feature has no impact on this task and discussing it on this task isnt helpful.

We should include a setting that either enables geshi or pygments. Since some users doint have python installed or doint want to use it but want to use something that is built to using php.

Please stop advocating the re-introduction of a PHP processor for SyntaxHighlight on this task and others. Create a new task for "additional processors" (and consider JavaScript solutions that would also solve the same problems.) If you really want a PHP solution, help the GeSHi developers get their code up to scratch. You'll need to build high quality tests to prove it is a maintainable backend.

Hi this task is about doing that. It is so we rename the repo to SyntaxHighlight and bring fed hi back in this extension. Meaning two different extensions.

The repository will be named "SyntaxHighlight" and will be based on the Pygments backend.
No need to add more comments to this task, in my opinion.

Is this something that can/should be done with the Gitlab migration?

In T103614#7309397, @Izno wrote:

Is this something that can/should be done with the Gitlab migration?

We'll do it after, not during, to avoid extra breakage, but yes.