Open main menu

Template talk:Extension

About this board

Archives 

/Archive 1


Link generated from table1 parameter is truncated

2
Edward Chernenko (talkcontribs)
Ciencia Al Poder (talkcontribs)
Reply to "Link generated from table1 parameter is truncated"
Jeblad (talkcontribs)

The status ladder seems slightly odd. The one I'm used to follow is the w:Debian style Experimental, Unstable, Testing, Stable, Oldstable, and Oldoldstable. The ladder this template use is unstable, experimental, beta, stable, unmaintained, archive, and unknown. Some of the states are clearly not similar, but the initial ones can give rise to quite worrisome misunderstandings. An extension flagged as unstable in Debian is way better than experimental, but unstable in this scheme is simply broken.

The term beta is also troublesome, as it relates to the release cycle. Typically a release cycle consists of alpha, beta, and release candidate. The status of the extension sets the limit for the final release quality, but it is not part of the release cycle. I believe the term beta should be removed. [Note that IBM use the alpha, beta, and release candidate for the w:Software release life cycle.]

Either the status ladder must be marked as non-standard, or the status ladder must follow an established standard. If it follows an established standard, then I would vote for using Debians status ladder.

Ciencia Al Poder (talkcontribs)

I don't think debian style ladder is useful here, since that applies to versions of a release, and not the current status of an extension

Jeblad (talkcontribs)

Versions of a (pre)release is (or should be) alpha, beta, and release candidate, while status is (or should be) Experimental, Unstable, Testing, and Stable. You can have several releases without ever changing the status.

Still what is really bad with our status ladder is our use of unstable as broken. That creates a lot of confusion.

Ciencia Al Poder (talkcontribs)

Ok, so let's not give them status name for now and just collect all the possible or interesting status:

  • Extensions that are maintained and kept up-to-date with the release lifecycle of MediaWiki, with no expected breaking changes.
  • Extensions with very active development that expect breaking changes as new features are being added.
  • Unmaintained extensions that are kept up-to-date by volunteers but there's no official maintainer. It can take months to fix bugs that make the extension unusable when a new MediaWiki version is released.
  • Unmaintained extensions that worked on previous versions of MediaWiki but are broken on recent versions of MediaWiki and there are no volunteers that provide patches for them to work (abandoned).

Those are the 4 status that I think would be useful to know about an extension.

Jeblad (talkcontribs)

I would say the order is

  1. (experimental) Extensions with very active development that expect breaking changes as new features are being added. (start-of-life)
  2. (unstable) Extensions that are out of the most active phase, is usable, but still without a live testing environment. An extension in unstable could have critical issues.
  3. (testing) Extensions that are out of the most active phase, and is usable, with a live testing environment. An extension in testing should not have critical issues. (The template should link to the testing environment.)
  4. (stable) Extensions that are maintained and kept up-to-date with the release lifecycle of MediaWiki, with no expected breaking changes.
  5. (oldstable) Unmaintained extensions that are kept up-to-date by volunteers but there's no official maintainer. It can take months to fix bugs that make the extension unusable when a new MediaWiki version is released.
  6. (abandoned) Unmaintained extensions that worked on previous versions of MediaWiki but are broken on recent versions of MediaWiki and there are no volunteers that provide patches for them to work. (end-of-life)
  7. (archived) After a one year grace period as abandoned the extension should be archived.

We should probably have some kind of badges on the extension page, like there are at Github, to show which extensions passes unit test, and also the number of open issues.

Ciencia Al Poder (talkcontribs)

I don't see how unstable and testing fits with extensions. What do you expect as a "testing environment"? Extensions in such a state can be in a production environment (live wikis not meant to be a testing wiki), and those names have no meaning about usability or critical issues, which is misleading. Unstable and testing shouldn't be considered IMHO.

Jeblad (talkcontribs)

A live testing environment is not the same as a production environment. You might set up a production environment with horribly broken software, nothing stops you. Having a testing environment imply that you have (integration) tests and can prove the extension work properly. That is you don't just include the extension and verify it shows up in Special:Version, you actually run real tests. That means most extensions for Mediawiki will only reach unstable, – not testing, not stable, and not oldstable. At some point such extensions go straight to abandoned.

Jeblad (talkcontribs)

An other way to explain it is a ladder of

  1. (experimental) Still being developed as one or more spikes and optionally stabilize, that is largely missing tests
  2. (unstable) Is predominantly developed as test and development cycles, that is it has at least unit tests
  3. (testing) Has public (live or for download) integration and unit tests with good coverage
  4. (stable) Has some form of release management

If you can't prove it to be working, then you can't claim it to be stable.

(Or as a co-worker told me once: Is a completely broken thing stable in its brokedness? It does not implement its intended functionality.)

Ciencia Al Poder (talkcontribs)

I'm against including the existence of coverage test to claim an extension is any of those statuses. A new property in the extension infobox to tell if the extensions has tests could be good, but not for the status of the extension, because it doesn't mean much.

Jeblad (talkcontribs)

And then we're back to why I believe the current status ladder is wrong; it has no real meaning, it is simply (made up) names.

IBMs old status ladder

  1. (pre-alpha) activities performed during the software project before formal testing (Wikibase while being modelled was here.)
  2. (alpha) first phase to begin software testing using white-box techniques
  3. (beta) the software is feature complete but likely to contain a number of known or unknown bugs (perpetual betas live here. This is unstable.)
  4. (release candidate) software with potential to be a final product, unless significant bugs emerge
  5. (stable) software released for general use
Ciencia Al Poder (talkcontribs)

That's more meaningful. Still, "release candidate" probably won't be used

Reply to "Status ladder"

Auto-updating based on extension.json

2
Bawolff (talkcontribs)

Just a heads up, I recently created a bot to auto-update Module:ExtensionJson, and want to experiment with auto-filling this template out based on extension.json data.

Sophivorus (talkcontribs)

This is probably the only way to really keep extension info updated.

Reply to "Auto-updating based on extension.json"
Shirayuki (talkcontribs)

Are license names translatable?

Legoktm (talkcontribs)

Hmm, quickly looking at d:Q7603, some languages do have it translated, but many more don't and use the English version...

Shirayuki (talkcontribs)
Shirayuki (talkcontribs)

Could we make license names translatable?

Reply to "license names translation"

Provide links to their Phabricator diffusions?

9
Liuxinyu970226 (talkcontribs)
Jdforrester (WMF) (talkcontribs)

Please, no. We're trying to stop people using Diffusion.

Kghbln (talkcontribs)

> We're trying to stop people using Diffusion.

I have already asked as for why before. This question was being ignored so far. As far as I am concerned we should link to Diffusion until somebody has the mercy and convenes to provide rationale to us beggars for not doing so.

Jdforrester (WMF) (talkcontribs)
Ciencia Al Poder (talkcontribs)

@Jdforrester (WMF): Can you post a more specific link? I don't see any mention about deprecation of diffusion on the RFC nor on the task.

Jdforrester (WMF) (talkcontribs)
Kghbln (talkcontribs)

Thanks a lot for the info. I guess the original intent of the question was to get a sane gui for looking at code and not for doing code changes. So a valid reason for not pointing to Diffusion is that it will be shut down also for code display. I am not sure if Gitlies is best of breed.

Jdforrester (WMF) (talkcontribs)

Indeed, I don't know what will change either. :-( However, right now, Gitiles is the "least bad" option.

Seb35 (talkcontribs)

I would like also a decent web viewer for code (and not code changes) and ultimately with a stable URL, e.g. to link from tasks to some specific lines of code and ultimately be able to read the same thing 10 years after.

Here the original request was to add a link to Diffusion (that) and not Differential. I do prefer Diffusion over Gitiles, even if I recently found there is the possibility to display by clicking on the branch 'master' (that).

Reply to "Provide links to their Phabricator diffusions?"

Per SPDX license list 3.0 (28 Dec 2017) release

7
Summary by Liuxinyu970226

tracked at phab:T183858

Liuxinyu970226 (talkcontribs)

Those old SPDX IDs are deprecated in favor of some new, clearly defined IDs:

  1. GNU Affero General Public License v3.0 (AGPL-3.0), splitted to GNU Affero General Public License v3.0 only (AGPL-3.0-only) and GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later)
  2. GNU Free Documentation License v1.1 (GFDL-1.1), splitted to GNU Free Documentation License v1.1 only (GFDL-1.1-only) and GNU Free Documentation License v1.1 or later (GFDL-1.1-or-later)
  3. GNU Free Documentation License v1.2 (GFDL-1.2), splitted to GNU Free Documentation License v1.2 only (GFDL-1.2-only) and GNU Free Documentation License v1.2 or later (GFDL-1.2-or-later)
  4. GNU Free Documentation License v1.3 (GFDL-1.3), splitted to GNU Free Documentation License v1.3 only (GFDL-1.3-only) and GNU Free Documentation License v1.3 or later (GFDL-1.3-or-later)
  5. GNU General Public License v1.0 only (GPL-1.0), replaced by GNU General Public License v1.0 only (GPL-1.0-only)
  6. GNU General Public License v2.0 only (GPL-2.0), replaced by GNU General Public License v2.0 only (GPL-2.0-only)
  7. GNU General Public License v3.0 only (GPL-3.0), replaced by GNU General Public License v3.0 only (GPL-3.0-only)
  8. GNU Library General Public License v2 only (LGPL-2.0), replaced by GNU Library General Public License v2 only (LGPL-2.0-only)
  9. GNU Lesser General Public License v2.1 only (LGPL-2.1), replaced by GNU Lesser General Public License v2.1 only (LGPL-2.1-only)
  10. GNU Lesser General Public License v3.0 only (LGPL-3.0), replaced by GNU Lesser General Public License v3.0 only (LGPL-3.0-only)
  11. Nunit License (Nunit), no replacement

What should we do per those changes?

Liuxinyu970226 (talkcontribs)

Note that they also re-added "GPLv1/2/3 or later" and "LGPLv2/2.1/3 or later" with new IDs (their old IDs are deprecated in version 2.0rc2):

  1. GNU General Public License v1.0 or later (GPL-1.0-or-later, was GPL-1.0+)
  2. GNU General Public License v2.0 or later (GPL-2.0-or-later, was GPL-2.0+) *The MediaWiki software is using old one!*
  3. GNU General Public License v3.0 or later (GPL-3.0-or-later, was GPL-3.0+)
  4. GNU Library General Public License v2 or later (LGPL-2.0-or-later, was LGPL-2.0+)
  5. GNU Lesser General Public License v2.1 or later (LGPL-2.1-or-later, was GNU Library General Public License v2 or later LGPL-2.1+)
  6. GNU Lesser General Public License v3.0 or later (LGPL-3.0-or-later, was LGPL-3.0+)
Legoktm (talkcontribs)

Probably we should add aliases for the old -> new, and at some point run a bot to migrate everything over. We're also going to need to update MediaWiki source code too, this will be fun!

I filed https://github.com/composer/spdx-licenses/issues/15 since that'll be the place to start on getting MediaWiki updated...

Kghbln (talkcontribs)

Meh, writing e.g. "GPL-2.0-or-later" instead of "GPL-2.0+" is not really an improvement besides making the obvious even more obvious. Do we want to change the string users have to add to the template or do we just change the module to display a different label for the same license?

Legoktm (talkcontribs)

Unfortunately, I've come across enough places where people just put GPL-2.0 when in reality it was -or-later. Hopefully this will fix that. I think in the beginning we should just change the text and accept both forms of the license, and once 3.0 becomes more widely used we can start updating existing pages to use the new version?

Kghbln (talkcontribs)

Sounds reasonable to me to do it like this. In the end it will be an extension by extension effort to check and amend the information. I am not sure if this change will provide an improvement since a lot of people just write GPL. Still there is hope for better awareness now. Moreover in case of uncertainty GPL-2.0 it is better to be added than GPL-2.0+, but that's another story.

Liuxinyu970226 (talkcontribs)
Reply to "Per SPDX license list 3.0 (28 Dec 2017) release"
Framawiki (talkcontribs)

Eg: take Extension:Newsletter

It would be great if we can have another section titled

Contributing

You can contribute to the extension by:

$ git clone ssh://<USERNAME>@gerrit.wikimedia.org:29418/mediawiki/extensions/Newsletter.git

Moved from phab:T165808 -- 01tonythomas

Tacsipacsi (talkcontribs)

This is an infobox, it’s not for short stories but for​ basic data. “Contributing” can be a section in the main text, or in a README file in the Git root.

Seb35 (talkcontribs)

I’m also enclined to be against such a change, at least in the current presentation of the infobox: I find there are already too much things in this infobox and it is already difficult to read. I find a general re-organisation of the whole infobox would be very welcome, perhaps removing some links and/or using pictograms for some links.

A step further about what Tacsipacsi suggests, perhaps a template Contribute could be created and transcluded in the page, something like Template:ExtensionInstall does for installation.

Reply to "Add a 'Contributing' section"
Shirayuki (talkcontribs)
Ciencia Al Poder (talkcontribs)

SOFIXIT?

Why not use always {{BASEPAGENAME}}? It should also work on english pages. You'll need also {{NAMESPACE}}.

Reply to "FULLPAGENAME"

no headings for readme and changelog, the whole "Download" section.

2
SPage (WMF) (talkcontribs)

In Extension:PieceOfCode I gave the readme parameter a value, but it just appears as an unidentified link under Download. I assume the same is true for changelog. The easy fix would be to provide link text for each, same as "Browse source code"

But with all these links, you're not downloading anything., so none belong under a Download column! They're just links to files that probably reflect the latest code, and the infobox seems to conflate this with "snapshot". It seems there should be a separate infobox section for Project, with links in it for browse source, view changes, readme, and changelog.

Ciencia Al Poder (talkcontribs)

Agree, although many of those links are generated by templates ({{GoogleCodeDownload}}, in that example), which would make it difficult to break into different sections

Reply to "no headings for readme and changelog, the whole "Download" section."

what should mediawiki parameter represent?

4
SPage (WMF) (talkcontribs)

Template parameters include

mediawiki
required version of MediaWiki

but is this the earliest version of MediaWiki for which there's a branch of the extension, or the earliest version of MediaWiki on which the extension's latest master will work?

There seems to be consensus that instead of the "master" branch supporting old MediaWiki releases, developers on releases should use the version of the extension tagged for that release from Special:ExtensionDistributor.

SPage (WMF) (talkcontribs)

In a related hack, in {{ExtensionInstall}} when it displays "To users running MediaWiki 1.24 or earlier: The instructions above describe the new way ..." I think[*] I added

(To run an extension on an earlier release, you may need to download the version of it tagged for that release from Special:ExtensionDistributor.)

It's really a more general point.

[*] I don't know how to test templates using TNT and translation.

Ciencia Al Poder (talkcontribs)

Note that even users running MediaWiki 1.25 should download the version tagged for that, because incompatibilities may happen if the extension was adapted to use new features introduced on master. This warning should probably be on the Special:ExtensionDistributor page

Ciencia Al Poder (talkcontribs)

It may also be "the latest know MediaWiki version where this extension has been tested and is supposed to work"

Reply to "what should mediawiki parameter represent?"
Return to "Extension" page.