Jump to content

Developer Wishlist/2017/Developer Environment: Difference between revisions

From mediawiki.org
Content deleted Content added
Line 122: Line 122:
#[[User:Tgr (WMF)|Tgr (WMF)]] ([[User talk:Tgr (WMF)|talk]]) 08:49, 8 February 2017 (UTC)
#[[User:Tgr (WMF)|Tgr (WMF)]] ([[User talk:Tgr (WMF)|talk]]) 08:49, 8 February 2017 (UTC)
#[[User:Tpt|Tpt]] ([[User talk:Tpt|talk]]) 09:10, 8 February 2017 (UTC)
#[[User:Tpt|Tpt]] ([[User talk:Tpt|talk]]) 09:10, 8 February 2017 (UTC)
#<span style="font-variant:small-caps">[[User:Ricordisamoa|<span style="color:#004B70">Ricordi</span>]][[User talk:Ricordisamoa|<span style="color:#00703E">samoa</span>]]</span> 11:13, 8 February 2017 (UTC)

Revision as of 11:13, 8 February 2017

Developer Wishlist 2017
Developer Environment

4 proposals, 49 editors, 71 votes

The voting phase has concluded. Thanks for participating!

You can view the results or discuss how to follow up.


Integrate a modern php REPL shell with MediaWiki

Currently MediaWiki provides a custom console via eval.php, which is integrated with the wiki's environment but otherwise rather poor (no proper readline support, no fatal error handling, the P part of REPL is missing, no tab autocompletion, no reflection...). Vagrant provides phpsh / hhvmsh which is somewhat better but still mediocre. It would be nice to replace these with a great REPL like PsySH or Boris.

Endorsements (T117661)

Support (T117661)

  1. Mainframe98 talk 09:31, 6 February 2017 (UTC)reply
  2. Osnard (talk) 12:53, 6 February 2017 (UTC)reply
  3. Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)reply
  4. MusikAnimal talk 16:42, 6 February 2017 (UTC)reply
  5. Amir E. Aharoni (talk) 16:58, 6 February 2017 (UTC)reply
  6. SIMOKHALIL (talk) 03:54, 7 February 2017 (UTC)reply
  7. Nikerabbit (talk) 07:59, 7 February 2017 (UTC)reply
  8. Samuele2002 (talk) 23:21, 7 February 2017 (UTC)reply

Good IDE integration convenient for everyone but especially helpful to new contributors who are not experienced coders - they have to learn a thousand new things from code review / distributed version control workflows to security back practices, and if we can avoid adding "learn how to tweak your IDE configuration" to that pile, we can make the learning curve significantly smoother.

A well-integrated IDE would

  • ensure that the right coding conventions are followed
  • do some of the CI checks in a much more user-friendly way (banana, autoloading etc.)
  • provide docs / typing / code completion / clickthrough navigation for systems which IDEs cannot figure out by default (e.g. hooks, global variables, extension-provided services, ResourceLoader modules)
  • maybe show docs/help from mediawiki.org
  • maybe warn when some MediaWiki best practices are not used (e.g. extension with PHP endpoint)

This does not mean that MediaWiki would be optimized to work with one IDE to the detriment of others, but it's nice to have a default.

PHPStorm integration already seems to have some momentum behind it, but which IDE we focus on is secondary to agreeing to focus on a single one.

Endorsements (T156873)

Support (T156873)

  1. Info-farmer (talk) 05:17, 6 February 2017 (UTC)reply
  2. Mainframe98 talk 09:33, 6 February 2017 (UTC)reply
  3. --Шухрат Саъдиев (talk) 11:31, 6 February 2017 (UTC)reply
  4. ·addshore· talk to me! 12:15, 6 February 2017 (UTC)reply
  5. Miriya52 (talk) 21:19, 6 February 2017 (UTC)reply
  6. Daniel Mietchen (talk) 22:22, 6 February 2017 (UTC)reply
  7. Info-Screen (talk) 05:37, 7 February 2017 (UTC)reply
  8. Liridon (talk) 12:11, 7 February 2017 (UTC)reply
  9. Samuele2002 (talk) 23:22, 7 February 2017 (UTC)reply
  10. Tpt (talk) 09:10, 8 February 2017 (UTC)reply

Integrate a modern debug/error display tool into MediaWiki

The MediaWiki ecosystem has some highly sophisticated loggin/debugging/error reporting tools such as the ELK stack, but they are nontrivial to set up and an effort to use (you need to go to the aggregation site and search for your error or log message, instead of just having it right on the wiki page where the error happened). It would be nice to integrate some modern error display / debug tool into MediaWiki for casual development - probably as an extension, since such tools tend to be insecure. A few possibilities:

Endorsements (T111731)

Support (T111731)

  1. Ladsgroup (talk) 09:56, 6 February 2017 (UTC)reply
  2. Frettie (talk) 10:03, 6 February 2017 (UTC)reply
  3. Amir E. Aharoni (talk) 13:47, 6 February 2017 (UTC)reply
  4. Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)reply
  5. Daniel Mietchen (talk) 22:23, 6 February 2017 (UTC)reply
  6. MusikAnimal talk 22:42, 6 February 2017 (UTC)reply
  7. [[kgh]] (talk) 23:24, 6 February 2017 (UTC)reply
  8. Santhosh.thottingal (talk) 03:31, 7 February 2017 (UTC)reply
  9. MSchottlender-WMF (talk) 05:29, 7 February 2017 (UTC)reply
  10. Liridon (talk) 12:11, 7 February 2017 (UTC)reply
  11. BSitzmann (WMF) (talk) 19:10, 7 February 2017 (UTC)reply
  12. MHolloway (WMF) (talk) 22:00, 7 February 2017 (UTC)reply
  13. Samuele2002 (talk) 23:22, 7 February 2017 (UTC)reply

Add support for a wmf-ci.yaml type file for wikimedia jenkins

Problem

Continuous Integration is hard to set up for repositories in the Wikimedia environment. Often this will require changes to the integration/config repo (e.g. editing a huge YAML file) and whitelisting of users (who may otherwise be unable to trigger some Jenkins jobs via Gerrit).

Proposed solution

Travis CI et similia only require a simple YAML file in the root directory of each code repository. Supporting such model can greatly streamline the addition of CI to repositories managed by small volunteer teams, decrease reliance on third-party services and ease the work of the few employees dedicated to CI infrastructure.


I discussed this on #wikimedia-releng and mmodell thought it was a nice idea, he is the one who came up with the name for the file. But this will help us customize it per repo without needing to create a separate job.

<twentyafterfour> paladox: it would be cool to do something similar to travis, with a test config file, indeed.

What we will do is have a major improvement over .travis-ci which will allow us to define multiple tests at the same time instead of being limited to 1.

An example on how it will look


project:
  - name: hi
  - php:
       - 7
       - 5.6
       - 5.5
       - 5.4
       - 5.3
       - hhvm
script:
  - composer test

This is a mock and will need improvements to support extending our tests without making it complex.


Endorsements (T145669)

Support (T145669)

  1. ·addshore· talk to me! 12:16, 6 February 2017 (UTC)reply
  2. Krinkle (talk) 19:27, 6 February 2017 (UTC)reply
  3. Nikerabbit (talk) 08:01, 7 February 2017 (UTC)reply
  4. MHolloway (WMF) (talk) 22:04, 7 February 2017 (UTC)reply
  5. Samuele2002 (talk) 23:23, 7 February 2017 (UTC)reply
  6. Tgr (WMF) (talk) 08:49, 8 February 2017 (UTC)reply
  7. Tpt (talk) 09:10, 8 February 2017 (UTC)reply
  8. Ricordisamoa 11:13, 8 February 2017 (UTC)reply