Thanks for the update. It's great to see the CoC processes improving
transparency and potentially accountability to the community.
It's worth noting how old the discussions are, with comments dating
back more than a year ago, especially in the context of how relatively
young the committee and the
Hello,
The CoC committee had a meeting with four members out of five (Lucie, Tony,
Tonina, and Amir were at Wikimania and MusikAnimal wasn't present). These
notes are the public outcomes of the meeting.
* The committee chose Amir as the chair (Amir requested to be the table but
it got rejected)
*
Hi,
for HTML version go to
https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-08-28
Željko
--
= 2019-08-28 =
== Callouts ==
* Release Engineering
** REMINDER: We're at 1.34.0-wmf.20 this week. The last branch for this
release will be wmf.25 on 30 September. Teams who want to ship things for
The 1.34.0-wmf.20 version of MediaWiki is blocked[0].
The new version is deployed to groups{0,1}[1], but can proceed no
further until these issues are resolved:
* T231542 AFPData.php: Refusing to cast DUNDEFINED to something else
* T231554 ApiQueryMapData.php: Call to a member function
On Thu, Aug 29, 2019 at 5:30 PM Daniel Kinzler wrote:
> But subclassing across module boundaries should be restricted to classes
> explicitly documented to act as extension points. If we could enforce this
> automatically, that would be excellent.
Well, for classes that aren't supposed to be
Am 29.08.19 um 15:31 schrieb Adam Wight:
> This is a solution I'd love to see explored. Subclassing is now considered
> harmful, and it would be possible to refactor existing cases to use
> interfaces, traits, composition, etc.
I wouldn't say subclassing is considered harmful in all cases. In
On Thu, Aug 29, 2019 at 3:50 PM Pine W wrote:
> Yes, I tink that a banner would be preferable, but i think that a notice on
> the homepage would be a reasonable backup option.
>
>
Thanks - Unfortunately I don't know if that is possible on Etherpad, I
don't have the knowledge to do so.
Maybe I
Yes, I tink that a banner would be preferable, but i think that a notice on
the homepage would be a reasonable backup option.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
On Thu, Aug 29, 2019, 06:28 Manuel Arostegui
wrote:
> On Thu, Aug 29, 2019 at 3:05 PM Pine W wrote:
>
> > Hello,
> >
On Wed, Aug 28, 2019 at 4:29 PM Daniel Kinzler
wrote:
> Subclassing should be very limited anyway, and even more limited across
> module
> boundaries [...]
This is a solution I'd love to see explored. Subclassing is now considered
harmful, and it would be possible to refactor existing cases
Note that https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/533067/ is
now ready for review, and works as expected. That could make this
discussion unnecessary.
Il giorno gio 29 ago 2019 alle ore 14:46 Aryeh Gregor ha
scritto:
> On Thu, Aug 29, 2019 at 1:02 AM Krinkle wrote:
> > What did
Hello,
Does this mean that https://etherpad.wikimedia.org/ will be temporarily
read only? That site seems to be somewhat popular for taking notes during
meetings. If that site will be affected then I recommend that you put up a
site notice there, possibly a multilingual one depending on how much
On Thu, Aug 29, 2019 at 1:02 AM Krinkle wrote:
> What did you want to assert in this test?
In a proper unit test, I want to completely replace all non-value
classes with mocks, so that they don't call the actual class' code.
This way I can test the class under test without making assumptions
Hello,
The current primary master for m1 (db1063), which is mostly for internal
services + etherpad isn't in a great healthy status: it is an old host,
which needs to be decommissioned and which is having disks failing pretty
much every week (plus disks on predictive failure).
We have decided to
Dear all,
I thank you for your efforts. I am managing to begin writing a survey about
wiki sites and publish it in an appropriate journal... This survey will involve
the software used (Mediawiki or other), the size, reference support, topic... I
am looking for contributors to this project.
On Thu, Aug 29, 2019 at 9:36 AM Daniel Kinzler
wrote:
>
> Narrow interfaces help with that. If we had for instance a cache interface
> that
> defined just the get() and set() methods, and that's all the code needs,
> then we
> can just provide a mock for that interface, and we wouldn't have to
> As such, to perhaps help with the conversation, I'd like to have a
> practical example we can look at and compare potential solutions. Perhaps
> from WANObjectCache, or perhaps with something else.
Simetrical can speak on the concrete use case, but I'd like to give my thoughts
on mocking
16 matches
Mail list logo