[Wikitech-l] Re: Best practices for extensions

[Ostrzyciel]

Hi Timo,

Thanks for clarifying this.

I would like to also point interested folks to the discussion taking 
place here: https://www.mediawiki.org/wiki/Topic:Wovr2kqb7qwhztwu


I think the MUST/SHOULD/OPTIONAL language was in a large part the 
initial source of my confusion.


Ostrzyciel

On 2/15/22 15:41, Krinkle wrote:

Hi Ostrzyciel. Replies inline.

On Thu, 27 Jan 2022, at 08:15, Ostrzyciel wrote:


Maybe a dumb question – I get a profound impression that this email 
*and* the guidelines are directed at Wikimedia employees, not 
MediaWiki extension developers in general.


...why? I thought that most extensions out there are not managed by 
Wikimedia, right?


These guidelines, and indeed most coding conventions and development 
guidelines, are directed at MediaWiki developers in general. They are 
not merely for WMF-maintained extensions or WMF staff.


Of the 70+ bullet points in the current draft, there are exactly 2 
points specific to WMF, and these are explicitly called out as such to 
avoid confusion (those are about sec/perf review, and stewardship).


The best practices document aims to reflect status quo among MediaWiki 
developers, which includes maintainers of the many MediaWiki hosted in 
Gerrit that aren't WMF-deployed. It is my understanding that by and 
large extensions follow the same coding styles, conventions, and 
guidelines. I also find in practice that volunteers contribute as much 
(if not, more than) staff to the shaping and implementation of these 
guidelines. Although these volunteers do tend to contribute more to 
WMF-deployed extensions, they are not currently staff.


In the latter case – are Wikimedia employees the right group to be 
guiding the discussion around these guidelines?




No. I specifically addressed the email to all/everyone, and all MW 
developers are welcome to participate. Extension maintainers often do 
follow these conventions. But, they are by no means required to. It's 
not a requirement for hosting (unlike e.g. licensing and code of 
conduct), and there are certainly numerous extensions that follow a 
different coding style, or don't follow any (publicly known) guidelines.


There is one line in the TLDR of my email where I called upon tech 
leads among WMDE/WMF staff. I recognise this may have set a confusing 
tone.


-- Timo



On 1/27/22 05:43, Krinkle wrote:
TLDR: Tech leads please review Best practices for extensions 
 on 
mediawiki.org.


Hi all,

You may be familiar with the Best practices for extensions 
 page 
on mediawiki.org. It has been marked as a draft since 2017.


I'd like to polish this page and get it to a state where it would be 
uncontroversial to label it as "Development guideline 
". This would 
not make it a hard policy. Neither does it imply that it covers all 
practices in all situations.


Rather, it would mean that the items that are there now are indeed a 
part of our current best practices. We would keep it alive through 
bold  edits and 
talk page conversations, similar to our Coding conventions 
 and 
other such guidelines that we maintain peer to peer and through 
consensus.


The reason I've not simply labelled it as such already is because 
before today I found the document to be out of sync with our actual 
practices. I have made a number of changes with descriptive edit 
summaries to bring it in sync with what I percieve to be our best 
practices; based on how myself and other maintainers perform code 
review at large, and how we review new extensions prior to deployment.


All are welcome to fix mistakes, raise questions/concerns on the 
talk page, on this thread. You're also welcome to message me 
directly anytime if you prefer.


If you consider yourself familiar with our practices and/or lead and 
mentor other engineers, please take a minute to review the page and 
consider whether the items reflect your current understanding and 
judgement.


--
Timo Tijhof,
Principal Engineer,
Wikimedia Performance Team.



___
Wikitech-l mailing list --wikitech-l@lists.wikimedia.org
To unsubscribe send an email towikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l]  Fresh 22.01 released!

[Krinkle]

This release adds the npx command, and updates Firefox (78esr to 90esr) and 
Chromium (90 to 97).

Get started by installing, updating, or learning more, at:
https://gerrit.wikimedia.org/g/fresh#fresh-environment

Changelog:
https://gerrit.wikimedia.org/g/fresh/+/22.01.1/CHANGELOG.md

As a reminder, the previous release changed the default "fresh-node" command to 
Node.js 12, and introduced fresh-node14 to use Node.js 14. The older Node.js 10 
environment. If you encounter problems with Node.js 12, let us know on 
Phabricator at https://phabricator.wikimedia.org/tag/fresh/. This is also where 
you can find recently resolved tasks.

Fresh is a fast way to create isolated environments from your terminal. These 
can be used to work more responsibly with 'npm' developer tools such as ESLint, 
QUnit, Grunt, Selenium, and more. Example guide: 
https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing

--
Timo Tijhof___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] [IMPORTANT] Announcing Toolforge Debian Stretch Grid Engine deprecation

[Seyram Komla Sapaty]

Hello, all!

This email contains valuable information about the Toolforge service.

Starting today, we're initiating a process to migrate away from Debian
Stretch to Debian Buster for all of Toolforge servers, and the most
affected piece is the Grid Engine backend in particular.

Debian Stretch was released in June 2017, and long term support for it
(including security updates) will cease in June 2022. We need to shut
down all Stretch hosts before the end of support date to ensure that
Toolforge remains a secure platform. This migration will take several
months because many people still use the Stretch hosts and our users
are working on tools in their spare time.

You should be aware that our ultimate goal is to deprecate Grid Engine
entirely and replace it with Kubernetes. Read below for more information
on this.

== Initial timeline ==
Subject to change, see Wikitech[1] for living timeline.

* 2022-02-15: Availability of Debian Buster grid announced to community
* 2022-03-21: Weekly reminders via email to tool maintainers for tools
still running on Stretch
* Week of 2022-04-21:
** Daily reminders via email to tool maintainers for tools still running on
Stretch
** Switch login.toolforge.org to point to Buster bastion
* Week of 2022-05-02: Evaluate migration status and formulate plan for
final shutdown of Stretch grid
* Week of 2022-05-21: Shut down Stretch grid

== What is changing? ==
* New bastion hosts running Debian Buster with connectivity to the new job
grid
* New versions of PHP, Python3, and other language runtimes
* New versions of various support libraries

== What should I do? ==
You should migrate your Toolforge tool to a newer environment.
You have two options:
* migrate from Toolforge Stretch Grid Engine to Toolforge Kubernetes[3].
* migrate from Toolforge Stretch Grid Engine to Toolforge Buster Grid
Engine.

The Cloud Services team has created the Toolforge Stretch
deprecation[0] page on wikitech.wikimedia.org to document basic steps
needed to move web services, cron jobs, and continuous jobs from the
old Stretch grid to the new Buster grid. That page also provides more
details on the language runtime and library version changes and will
provide answers to common problems people encounter as we find them.
If the answer to your problem isn't on the wiki, ask for help using
any of our communication channels[2].

We encourage you to move to Kubernetes today if you can, see below for
more details.

For those who can't migrate to Kubernetes, the Debian Buster grid should
be adopted within the next three months.

== A note on the future of Toolforge, the Grid and Kubernetes ==
As of today, Toolforge is powered by both Grid Engine and Kubernetes.
For a number of reasons, we have decided to deprecate Grid Engine and
replace all of its functions with Kubernetes. We're not yet ready to
offer all grid-like features on Kubernetes, but we're working on it.
As soon as we are able, we will begin the process of migrating the
workloads and shutting down the grid. This is something we hope to do
between 2022 and 2023.

We share this information to encourage you to evaluate migrating your
tool away from Grid Engine to Kubernetes.

One of the most prominent missing features on Kubernetes was a friendly
command line interface to schedule jobs (like jsub). We've been working
on that, and have a beta-level interface that you can try today: the
Toolforge jobs framework [4].

[0]: https://wikitech.wikimedia.org/wiki/News/Toolforge_Stretch_deprecation
[1]:
https://wikitech.wikimedia.org/wiki/News/Toolforge_Stretch_deprecation#Timeline
[2]:
https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Communication_and_support
[3]: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes
[4]: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs-Framework

Thanks.

-- 
Seyram Komla Sapaty
Developer Advocate
Wikimedia Cloud Services
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Best practices for extensions

[Krinkle]

Hi Ostrzyciel. Replies inline.

On Thu, 27 Jan 2022, at 08:15, Ostrzyciel wrote:
> Maybe a dumb question – I get a profound impression that this email *and* the 
> guidelines are directed at Wikimedia employees, not MediaWiki extension 
> developers in general.
> 
> ...why? I thought that most extensions out there are not managed by 
> Wikimedia, right?

These guidelines, and indeed most coding conventions and development 
guidelines, are directed at MediaWiki developers in general. They are not 
merely for WMF-maintained extensions or WMF staff.

Of the 70+ bullet points in the current draft, there are exactly 2 points 
specific to WMF, and these are explicitly called out as such to avoid confusion 
(those are about sec/perf review, and stewardship).

The best practices document aims to reflect status quo among MediaWiki 
developers, which includes maintainers of the many MediaWiki hosted in Gerrit 
that aren't WMF-deployed. It is my understanding that by and large extensions 
follow the same coding styles, conventions, and guidelines. I also find in 
practice that volunteers contribute as much (if not, more than) staff to the 
shaping and implementation of these guidelines. Although these volunteers do 
tend to contribute more to WMF-deployed extensions, they are not currently 
staff.

> In the latter case – are Wikimedia employees the right group to be guiding 
> the discussion around these guidelines?
> 

No. I specifically addressed the email to all/everyone, and all MW developers 
are welcome to participate. Extension maintainers often do follow these 
conventions. But, they are by no means required to. It's not a requirement for 
hosting (unlike e.g. licensing and code of conduct), and there are certainly 
numerous extensions that follow a different coding style, or don't follow any 
(publicly known) guidelines.

There is one line in the TLDR of my email where I called upon tech leads among 
WMDE/WMF staff. I recognise this may have set a confusing tone.

-- Timo


> On 1/27/22 05:43, Krinkle wrote:
>> TLDR: Tech leads please review Best practices for extensions 
>>  on 
>> mediawiki.org.
>> 
>> Hi all,
>> 
>> You may be familiar with the Best practices for extensions 
>>  page on 
>> mediawiki.org. It has been marked as a draft since 2017.
>> 
>> I'd like to polish this page and get it to a state where it would be 
>> uncontroversial to label it as "Development guideline 
>> ". This would not 
>> make it a hard policy. Neither does it imply that it covers all practices in 
>> all situations.
>> 
>> Rather, it would mean that the items that are there now are indeed a part of 
>> our current best practices. We would keep it alive through bold 
>>  edits and talk page 
>> conversations, similar to our Coding conventions 
>>  and other 
>> such guidelines that we maintain peer to peer and through consensus.
>> 
>> The reason I've not simply labelled it as such already is because before 
>> today I found the document to be out of sync with our actual practices. I 
>> have made a number of changes with descriptive edit summaries to bring it in 
>> sync with what I percieve to be our best practices; based on how myself and 
>> other maintainers perform code review at large, and how we review new 
>> extensions prior to deployment.
>> 
>> All are welcome to fix mistakes, raise questions/concerns on the talk page, 
>> on this thread. You're also welcome to message me directly anytime if you 
>> prefer.
>> 
>> If you consider yourself familiar with our practices and/or lead and mentor 
>> other engineers, please take a minute to review the page and consider 
>> whether the items reflect your current understanding and judgement.
>> 
>> --
>> Timo Tijhof,
>> Principal Engineer,
>> Wikimedia Performance Team.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] new extension PageProperties

[Thomas]

hello,

    I have published recently the extension PageProperties

 

https://www.mediawiki.org/wiki/Extension:PageProperties

 

it is mainly a page properties aggregator where users can

set display title, language and content model of a page, in one place, 

plus defining SEO meta data and 

Semantic Mediawiki properties (provided that SMW is installed)

without annotating them manually on the page.

 

It partly develops the concept of "Enterprise Mediawiki" mentioned here

https://phabricator.wikimedia.org/T149612

 

(together with other extensions which are either in beta status, or not yet

published that I plan to publish progressively.)

 

Technically, it uses the _javascript_ tabs used by PreferencesFormOOUI,

plus other pieces taken from the DisplayTitle extension (mentioned within

the code) and from the special pages SpecialPageLanguage and

SpecialChangeContentModel, and of course original code.

 

 

Kind regards

(Thomas)

 

 

 

 ___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/