Page MenuHomePhabricator

Restore WikiEditor on packagist.org, so that it's installable via composer
Closed, DeclinedPublic

Description

This morning I tried to update my wikieditor via Composer just to realize that suddenly it has disappeared from packagist.org just to spend an hour to find out that someone from WMF had merged a patch [0] without consulting potential users.

I'm honestly without words that WMF (or those who act on behalf of WMF and with +2 merge rights) engage in arbitrary deletion, now leaving me with an unstable deployment.

[0] https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FWikiEditor/11781784defaa433126dfad0585d26101910c178

Event Timeline

mwjames created this task.Mar 23 2015, 6:00 PM
mwjames assigned this task to Legoktm.
mwjames raised the priority of this task from to Needs Triage.
mwjames updated the task description. (Show Details)
mwjames added subscribers: mwjames, Kghbln, MarkAHershberger.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 23 2015, 6:00 PM

Is this an actual bug report? What action do you want to be taken?

If you're running "dev-*", I don't understand how you would expect it to be stable.

Legoktm set Security to None.

Would be appropriate to CC the people you're mentioning, no?

People found the composer functionality useful, so removing it could be considered a bug.

The concept of "maintainers" (mentioned in the commit to remove the support) is pretty fluid, but I'm not sure what basis it has. Kunal made that commit claiming the "maintainers" (who?) aren't supporting composer, but I don't see him in any other recent commits by him, so I'm not sure why he is claiming to know what the maintainers think.

I'm interested in what other developers (Alex Monk, Paladox, Brion, Hashar) who have made recent commits or supplied the initial composer support have to say on this issue.

I think removing support for installation-by-composer while adding support for "composer test" seems a little backwards.

WikiEditor, along with about fifty other extensions, is owned by the #Editing department.

Also, the "If you're running 'dev-*' ..." reasoning seems weak to me given the WMF's schedule for rolling out changes to Wikipedia. Not that the changes are untested (they work very well), but that to keep current with WMF development, you have to be willing to update frequently and, for many people, this means "dev".

I guess what I'm saying is that people have come to expect essentially production quality from the master branch. This says a lot of good things about software engineering at WMF. I don't think it is a good idea to tell people that master branches shouldn't be relied on.

twn, for example, has a long history -- even back in subversion days -- of acting as a canary in the coal mine for MW code.

WikiEditor, along with about fifty other extensions, is owned by the #Editing department.

Makes sense.

Since installation-via-composer support has been contributed and maintained by people not in the #Editing department, is there any reason to remove it now if other people are willing to continue to support it?

hashar removed a subscriber: hashar.Mar 24 2015, 8:43 AM
Aklapper added a subscriber: Qgil.Mar 24 2015, 10:30 AM

Is this an actual bug report? What action do you want to be taken? If you're running "dev-*", I don't understand how you would expect it to be stable.

Yes, because you arbitrarily deleted something others might find useful. You deleted content from the composer.json so that it can't be re-registered in packagist.org (by a non-WMF staff).

If you want to promote your extension.json that is one thing but removing something so that third-party users cannot choose their own deployment strategy is a completely different thing.

WikiEditor, along with about fifty other extensions, is owned by the Editing department.

This statement implies that you are authorized to delete whatever fits your internal departmental purpose? I doubt that very much.

This existence of the composer.json does not alter existing functionality nor does it interfere with the way how WMF uses the extension but it allows others (non WMF users) to make a different choice on how they facilitate this extension.

Qgil added a subscriber: greg.Mar 26 2015, 8:39 PM

The concept of "maintainers" (mentioned in the commit to remove the support) is pretty fluid, but I'm not sure what basis it has. Kunal made that commit claiming the "maintainers" (who?) aren't supporting composer, but I don't see him in any other recent commits by him, so I'm not sure why he is claiming to know what the maintainers think.

Because I spoke with the maintainers (James F specifically) and asked their opinion?

I think removing support for installation-by-composer while adding support for "composer test" seems a little backwards.

Why?

Legoktm writes:

I think removing support for installation-by-composer while adding
support for "composer test" seems a little backwards.

Why?

Because you are working to improve the module's integration with
composer ("composer test") but then removing integration that is already
there ("composer install") that is more likely to have been used.

Change 200305 had a related patch set uploaded (by MarkAHershberger):
Restore support for 'composer install'

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

Please +2 the patch and re-register this extension in packagist.

We should probably also start too look for other extensions that had "composer install" removed since that could cause problems for people's MediaWiki installations.

greg added a comment.Mar 28 2015, 10:24 PM

Also, the "If you're running 'dev-*' ..." reasoning seems weak to me given the WMF's schedule for rolling out changes to Wikipedia. Not that the changes are untested (they work very well), but that to keep current with WMF development, you have to be willing to update frequently and, for many people, this means "dev".

No one needs to keep current with WMF deployments other than WMF. Choosing to use unreleased branches is a choice, not a given.

I guess what I'm saying is that people have come to expect essentially production quality from the master branch. This says a lot of good things about software engineering at WMF. I don't think it is a good idea to tell people that master branches shouldn't be relied on.

master can be relied upon if you want, but the pace at which it is updated is hard for anyone (including other full-time devs in the WMF) to keep up with. There is no expectation that anything added at one point in master will stay in master at another point. That's what releases are for.

Because you are working to improve the module's integration with
composer ("composer test") but then removing integration that is already
there ("composer install") that is more likely to have been used.

No, I was adding the ability to run phpcs in the way recommended by our CI system (docs). Looking back now it would have been better to make two distinct commits, one to remove "composer install" support, and another to add a command to run phpcs.

Please +2 the patch and re-register this extension in packagist.

Please actually test your patches before asking people to +2 them.

Please actually test your patches before asking people to +2 them.

You're right. Or I could even just check that they pass the tests that jenkins does.

No one needs to keep current with WMF deployments other than WMF.

On its face, this is true.

But, the reality of using VE is that if you discover any problems (which is very likely right now), it will only be fixed in master and not back-ported to any previous branches. Amir even mentioned how hard it was tso use VE without keeping current with WMF's version of MW at the dev summit.

Nemo_bis renamed this task from Wikieditor (Revert making installable via composer) to Restore WikiEditor on packagist.org, so that it's installable via composer.Apr 1 2015, 9:13 AM
Nemo_bis triaged this task as Medium priority.
Nemo_bis added a project: Regression.
Nemo_bis added a subscriber: Nemo_bis.EditedApr 1 2015, 9:15 AM

I agree that removing an extension from packagist.org/composer install should be done only after a phabricator report is filed, adding known users to Cc, and that users should be allowed to restore the package under another name if the current maintainer can't continue offering it.

Toniher added a subscriber: Toniher.Apr 9 2015, 3:27 PM

Change 200305 abandoned by MarkAHershberger:
Restore support for 'composer install'

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

Umherirrender closed this task as Declined.Jan 1 2017, 8:57 PM
Umherirrender added a subscriber: Umherirrender.

per T467

happy5214 moved this task from Backlog to Closed on the WikiEditor board.Aug 4 2019, 12:00 PM