Jump to content

Developer Wishlist/2017/Developer Environment

From mediawiki.org
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

Tracked in Phabricator
Task T117661

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)

  1. Fixing Unicode and such stuff is definitely needed, but I don't have an opinion on the need for a "modern php REPL shell". --Nemo 18:14, 14 February 2017 (UTC)[reply]

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]
  9. Edward Chernenko (talk) 22:19, 9 February 2017 (UTC)[reply]
  10. Smalyshev (WMF) (talk) 02:23, 10 February 2017 (UTC)[reply]
  11. Samuele2002 (talk) 18:38, 11 February 2017 (UTC)[reply]
  12. 47.222.203.135 17:21, 13 February 2017 (UTC)[reply]
  13. Zulfiqar Anees (talk) 02:45, 14 February 2017 (UTC)[reply]
  14. B20180 (talk) 13:41, 14 February 2017 (UTC)[reply]
Tracked in Phabricator
Task T156873

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 best-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)

  1. It's indeed good to help people set up their editor/IDE, at a minimum by improving the documentation at Manual:Coding conventions (there's already something for nano and a few other editors). I find it unlikely that we would agree on using a single editor though. Nemo 18:13, 14 February 2017 (UTC)[reply]

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]
  11. Headbomb (talk) 20:51, 8 February 2017 (UTC)[reply]
  12. Calexit (talk) 22:15, 9 February 2017 (UTC)[reply]
  13. NKohli (WMF) (talk) 12:41, 10 February 2017 (UTC)[reply]
  14. Martin Urbanec (talk) 18:09, 13 February 2017 (UTC)[reply]
  15. Lluis tgn (talk) 14:18, 14 February 2017 (UTC)[reply]
  16. Framawiki (talk) 17:32, 14 February 2017 (UTC)[reply]

Integrate a modern debug/error display tool into MediaWiki

Tracked in Phabricator
Task T111731

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)

  1. I agree on the need for something simple for casual development, but I don't have opinions on the proposed solution. Nemo 18:11, 14 February 2017 (UTC)[reply]

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]
  14. Cindy.cicalese (talk) 14:09, 8 February 2017 (UTC)[reply]
  15. Smalyshev (WMF) (talk) 02:22, 10 February 2017 (UTC)[reply]
  16. NKohli (WMF) (talk) 12:41, 10 February 2017 (UTC)[reply]
  17. Vikramds (talk) 07:17, 11 February 2017 (UTC)[reply]
  18. Helder 17:40, 12 February 2017 (UTC)[reply]
  19. Sebastian Berlin (WMSE) (talk) 09:59, 13 February 2017 (UTC)[reply]
  20. Mglaser (talk) 10:12, 13 February 2017 (UTC)[reply]
  21. Osnard (talk) 11:33, 13 February 2017 (UTC)[reply]
  22. James Martindale (talk) 16:56, 13 February 2017 (UTC)[reply]
  23. Strongest possible. 47.222.203.135 17:21, 13 February 2017 (UTC)[reply]
  24. Martin Urbanec (talk) 18:10, 13 February 2017 (UTC)[reply]
  25. TerraCodes (talk) 20:57, 13 February 2017 (UTC)[reply]
  26. Zulfiqar Anees (talk) 02:44, 14 February 2017 (UTC)[reply]
  27. B20180 (talk) 13:41, 14 February 2017 (UTC)[reply]
  28. Framawiki (talk) 17:32, 14 February 2017 (UTC)[reply]
  29. Quiddity (WMF) (talk) 20:24, 14 February 2017 (UTC)[reply]

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

Tracked in Phabricator
Task T145669

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]
  9. André Costa (WMSE) (talk) 15:19, 8 February 2017 (UTC)[reply]
  10. Samuele2002 (talk) 18:37, 11 February 2017 (UTC)[reply]
  11. B20180 (talk) 13:40, 14 February 2017 (UTC)[reply]
  12. Nemo 18:10, 14 February 2017 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Developer_Wishlist/2017/Developer_Environment&oldid=2397339"