Re: [Wikitech-l] My intro

[Egbe Eugene]

Hi Fabrice,

I will suggest you read through the GSoC documentation provided by Andre
thoroughly so you can know well about the program.

On Thu, Mar 12, 2020 at 10:10 PM fabrice ngoran 
wrote:

> Sorry to border you, but it's my first time taking part in such events.
> I've found tasks on the page you directed my to. What are they for?
> Plsss
> On Mar 12, 2020 9:28 PM, "fabrice ngoran" 
> wrote:
>
> > Thank you Andre
> > On Mar 12, 2020 7:39 PM, "Andre Klapper"  wrote:
> >
> >> Hi and welcome!
> >>
> >> On Thu, 2020-03-12 at 18:58 +0100, fabrice ngoran wrote:
> >> > Hi,
> >> > I'm Fabrice, new to the organization. I heard of gsoc very late but
> >> still
> >> > decided to give it a try. I don't know much on how/where to
> communicate
> >> > with members of the organization. I'll be really grateful if someone
> >> could
> >> > help me out.🙏
> >>
> >> Glad to hear your interest in contributing to Wikimedia projects!
> >> Please see https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020
> >> for more information and communication venues.
> >>
> >> Thanks,
> >> andre
> >> --
> >> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> >> https://blogs.gnome.org/aklapper/
> >>
> >>
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My intro

[fabrice ngoran]

Sorry to border you, but it's my first time taking part in such events.
I've found tasks on the page you directed my to. What are they for?
Plsss
On Mar 12, 2020 9:28 PM, "fabrice ngoran"  wrote:

> Thank you Andre
> On Mar 12, 2020 7:39 PM, "Andre Klapper"  wrote:
>
>> Hi and welcome!
>>
>> On Thu, 2020-03-12 at 18:58 +0100, fabrice ngoran wrote:
>> > Hi,
>> > I'm Fabrice, new to the organization. I heard of gsoc very late but
>> still
>> > decided to give it a try. I don't know much on how/where to communicate
>> > with members of the organization. I'll be really grateful if someone
>> could
>> > help me out.🙏
>>
>> Glad to hear your interest in contributing to Wikimedia projects!
>> Please see https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020
>> for more information and communication venues.
>>
>> Thanks,
>> andre
>> --
>> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
>> https://blogs.gnome.org/aklapper/
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My intro

[fabrice ngoran]

Thank you Andre
On Mar 12, 2020 7:39 PM, "Andre Klapper"  wrote:

> Hi and welcome!
>
> On Thu, 2020-03-12 at 18:58 +0100, fabrice ngoran wrote:
> > Hi,
> > I'm Fabrice, new to the organization. I heard of gsoc very late but still
> > decided to give it a try. I don't know much on how/where to communicate
> > with members of the organization. I'll be really grateful if someone
> could
> > help me out.🙏
>
> Glad to hear your interest in contributing to Wikimedia projects!
> Please see https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020
> for more information and communication venues.
>
> Thanks,
> andre
> --
> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My intro

[Andre Klapper]

Hi and welcome!

On Thu, 2020-03-12 at 18:58 +0100, fabrice ngoran wrote:
> Hi,
> I'm Fabrice, new to the organization. I heard of gsoc very late but still
> decided to give it a try. I don't know much on how/where to communicate
> with members of the organization. I'll be really grateful if someone could
> help me out.🙏

Glad to hear your interest in contributing to Wikimedia projects!
Please see https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020
for more information and communication venues.

Thanks,
andre
-- 
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] My intro

[fabrice ngoran]

Hi,
I'm Fabrice, new to the organization. I heard of gsoc very late but still
decided to give it a try. I don't know much on how/where to communicate
with members of the organization. I'll be really grateful if someone could
help me out.🙏
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Milestone: CI now running PHP 7.4 tests as voting

[James Forrester]

All,

Ahead of the release of MediaWiki 1.35.0, a number of people have been
working to make sure that MediaWiki is compatible with PHP 7.4.[0] We have
now reached the final phase of that work, where we are checking that we
don't regress in CI. This is running on the master branch, as REL1_34 is
not compatible.

To that end, * Wikimedia CI is now running PHP 7.4 as voting* for almost
all PHP code. This covers MediaWiki core, most extensions, skins, and
libraries. PHP74 jobs will appear in the 'gate-and-submit' and 'php'
pipelines for your projects.

If your code works in PHP 7.3 but not in PHP 7.4, it will now fail. Most of
the changes are documented in PHP's migration guidance.[1] Note that this
is rare; almost all PHP 7.2- and 7.3-compatible code works fine in PHP 7.4.

There are a few extensions which are known to not yet be PHP
7.4-compatible, and so currently aren't running PHP74 tests yet; others
will probably exist. I've spot-checked a few dozen projects, and fixed
several issues, but it is likely that I have missed some; we have well over
a thousand repos, after all.

If your repo is broken by this change and needs the PHP 7.4 testing
temporarily removed, please file a task on the workboard[2] and I'll be
happy to get it fixed.

Thank you to everyone who has worked on this.

[0] - https://phabricator.wikimedia.org/T233012
[1] - https://www.php.net/manual/en/migration74.php
[2] - https://phabricator.wikimedia.org/tag/php_7.4_support/

Yours,
-- 
*James D. Forrester* (he/him  or they/themself
)
Wikimedia Foundation 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Train] 1.35.0-wmf.23 status update (blocked)

[Brennen Bearnes]

The 1.35.0-wmf.23 version of MediaWiki is blocked[0].

The new version can't proceed to group2 [1] until these issues are 
resolved, and may be rolled back to group0 if necessary:


* T247458 PHP Notice: Undefined index: wgKartographerLiveData
- https://phabricator.wikimedia.org/T247458

* T247466 SimpleCacheWithBagOStuff: Cache key contains characters that 
are not allowed

- https://phabricator.wikimedia.org/T247466

* T247484 Lots of "EventBus: Unable to deliver all events"
- https://phabricator.wikimedia.org/T247484

If all issues are resolved before 15:00 PST, the train can resume today, 
otherwise the train will resume Monday, March 16th at the earliest.


Thank you for your help resolving these issues!

-- Your harried train functionary

[0]. 
[1]. 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] m2 (OTRS, recommendations_api, gerrit, debmonitor) primary database restart

[Manuel Arostegui]

Hello,

This has been rescheduled from Tuesday 17th 09:00 AM UTC to Thursday 19th
09:00 AM UTC

Sorry for any inconvenience.

Manuel.

On Tue, Mar 10, 2020 at 11:52 AM Manuel Arostegui 
wrote:

> Hello,
>
> Tuesday 17th at 09:00 AM UTC we will be restarting db1132 as part
> of T239791.
> We will take the opportunity to upgrade MySQL there.
>
> m2 holds the following databases:
>
> - OTRS
> - Recommendations API
> - Reviewdb (gerrit)
> - Debmonitor
>
> We expect read-only time to be around 30-60 seconds, also, gerrit might be
> unavailable as well.
> Coordination will happen on #wikimedia-operations
>
> Thanks!
> Manuel.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Last Call: Updated Stable Interface Policy / Deprecation Policy

[Daniel Kinzler]

Hi all!

Per yesterday's TechCom meeting, the last call ended without any concerns being
raised. If you work on extensions or MediaWiki core, please read through the
changes outlined below, and have a look at the policy page at
.

Thanks!

Am 28.02.20 um 11:38 schrieb Daniel Kinzler:
> Hi all!
> 
> TL;DR: A new policy defining stable interfaces for use by extensions, and the
> deprecation process that must be followed when changing such stable 
> interfaces,
> is now in the Last Call period. If no concerns remain unaddressed by March 11,
> the new policy will be adopted as official policy. The policy will apply to
> MediaWiki 1.35 and later.
> 
> The new policy is designed to better protect extensions from breakage when
> things change in core, by being more restrictive about what extensions can
> safely do.
> 
> Draft document: https://www.mediawiki.org/wiki/Stable_interface_policy
> RFC ticket: https://phabricator.wikimedia.org/T193613
> 
> Please comment there. Read below for a summary of changes.
> 
> 
> Long version:
> 
> TechCom has been working on a Stable Interface Policy for MediaWiki's PHP code
> for a while[1]. Previously, the definition of the stable interface that can be
> used by extensions was part of the Deprecation Policy[2]. The new policy[3] is
> much more detailed and explicit about what extensions can expect to remain
> stable and follow the deprecation process, and which things can change without
> notice.
> 
> The introduction of the new policy is driven by problems we found while trying
> to refactor core code with the aim to reduce coupling. For instance, when
> following the Dependency Injection pattern, the constructor of service classes
> is technically public, but is not stable for use outside the module.
> 
> The solution is to be more explicit about different kinds of stability (e.g.
> whether a method is stable for callers, or can also be safely overwritten).
> 
> To allow us more freedom to restructure the source code, the new policy is 
> more
> restrictive with respect to what extensions can expect to be able to do safely
> (e.g. subclass core classes). This is balanced by improved guarantees in
> previously unspecified cases (e.g. stability of protected methods).
> 
> The new policy specifies different kinds of stability, establishes defaults 
> for
> different parts of the code, and defines new annotations to be used in the
> documentation. Once the policy has been adopted, these annotations are soon to
> be added to the code.
> 
> This will hopefully allow us to more quickly improve the structure and quality
> of core code, and reduce the risk of breaking extensions in the future.
> 
> 
> Summary of the new policy:
> 
> For extension authors:
> 
> * It's generally safe to call public methods, and to access public fields in
> classes defined by MediaWiki core, unless these methods are documented to be
> unsafe (e.g. annotated as @deprecated, @unstable, or @internal).
> 
> * It's generally unsafe to extend (subclass) classes or implement interfaces
> defined by MediaWiki core, unless that class or interface was marked as 
> @stable
> for subclassing or @stable for implementation, respectively. In particular, 
> the
> constructor signature may change without notice, and abstract methods may be
> added to interfaces.
> 
> * It's generally unsafe to directly instantiate (using new) classes defined by
> MediaWiki core, unless that class is marked as @newable.
> 
> * It's generally unsafe to rely on global variables from MediaWiki core. Use
> methods such as MediaWikiServices::getInstance() or
> MediaWikiServices::getMainConfig() instead.
> 
> 
> When changing existing code:
> 
> * Keep public methods and hook signatures backwards compatible for callers.
> Follow the deprecation process when removing them.
> 
> * Keep constructor signatures backwards compatible if the constructor was 
> marked
> @stable for calling.
> 
> * Ensure compatibility of method signatures for code that overrides them if 
> they
> are marked @stable for overriding.
> 
> * Do not add abstract methods to classes or interfaces marked as @stable for
> subclassing or @stable for implementation.
> 
> 
> When defining extension points:
> 
> * When defining hooks, keep the signature minimal, and expose narrow 
> interfaces,
> ideally only pure value objects.
> 
> * When defining an interface to be implemented by extensions, provide a base
> class, and mark it as @stable for subclassing.
> 
> * Discourage extensions from directly implementing interfaces by marking them 
> as
> @unstable for implementation. If direct implementation is to be allowed, mark
> the interface @stable for implementation.
> 
> 
> Notable changes from the 1.34 policy:
> 
> * Public methods are per default considered stable only for calling, not for
> overriding.
> 
> * Constructors are considered unstable per default.
> 
> * Classes and interfaces are considered unstable for subcla