Manual talk:Developing libraries

Automated style checks

"Automated style checks are STRONGLY encouraged..."

Can you point to a place where this is done? I'm using MediaWiki coding style for a lot of my libraries though do not have any style checking in place, so I'm curious on how to do this well.

--Jeroen De Dauw (talk) 18:36, 31 December 2014 (UTC)

We have a set of codesniffer rules that are run on the WMF Jenkins servers. The rules are in gerrit at git:tools/codesniffer. I have opened phab:T85631 to track getting this package to include a composer.json and publishing to Packagist to make including it in local tests and via services like Travis easier. --BDavis (WMF) (talk) 18:50, 31 December 2014 (UTC)

The MediaWiki codesniffer rules are now available via Packagist. --BDavis (WMF) (talk) 17:33, 13 January 2015 (UTC)

Users

These 12 sections are important, thanks for compiling them. However, none of them is relevant to the only question users have: "will my wiki still work?". If we want guidelines, we need principles about the end result. For example:

• the tarball must just work;
• an official packagist package needs to be made available (with [1]?) if it isn't yet;
• packagers (e.g. Debian package maintainer) need to agree with the guidelines/continue providing the same level of service or higher;
• no additional step(s) must be added to the installation process;
• the list of requirements must always be complete, but should get shorter for the typical user and/or less relevant (e.g. we should support more platforms, not less, by including libraries);
• the initial clone/install for a developer should not be longer than X (hours? no idea how to measure).

--Nemo 08:22, 8 January 2015 (UTC)

These are all great points of discussion for packaging and distributing MediaWiki. I think they are especially important to discuss and come to consensus on soon as the discussions of migrating the MediaWiki deployment used by the Wikimedia Foundation to power Wikipedia and the other Foundation projects to a service oriented architecture are a major topic of the upcoming developer summit. Specifically "the tarball must just work", "no additional step(s) must be added to the installation process" and "should support more platforms, not less" are likely casualties of a true SOA architecture.

Specific to this this RFC, I think "an official packagist package needs to be made available" could be directly addressed. The other items are more related to tooling and support for packaging and distribution than the code base or libraries themselves in my estimation. --BDavis (WMF) (talk) 17:31, 13 January 2015 (UTC)

I agree with the move to the Manual namespace: as a manual, the content is very useful. Manual:Developing_libraries#Packagist guidelines looks straightfoward enough. I still think actual guidelines should be produced to address the points above, are they on-topic for another of the open RfCs? --Nemo 10:27, 22 January 2015 (UTC)

Gerrit

It is worth mentioning http://gerrithub.io under 'code review'? I used it for a non-WMF project and it's not bad. cscott (talk) 21:54, 14 January 2015 (UTC)

Added reference in revision 1356581. I couldn't bring myself to endorse it. :) --BDavis (WMF) (talk) 04:13, 16 January 2015 (UTC)

"GitHub-hosted projects can use Travis"

Unless I'm mistaken, projects that are hosted in Gerrit and merely mirrored to github can also use Travis. Should this sentence be rephrased? Anomie (talk) 17:20, 25 January 2018 (UTC)

You are correct, so yes. Anything that is mirrored to GitHub can use Travis CI. I guess the fundamental difference would be doing pre-merge testing via Travis. A Gerrit or Phabricator hosted repo would only have feature branches and master mirrored to GitHub after patches are merged. --BDavis (WMF) (talk) 23:33, 25 January 2018 (UTC)

RFC dead link on bots.wmflabs.org

At this section The decision link is dead -> https://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20150114.txt  ; can someone realign please ? Thanks. -- Christian 🇫🇷 FR (talk) 13:32, 15 January 2024 (UTC)