Re: [Wikitech-l] Can we drop revision hashes (rev_sha1)?

[Daniel Kinzler]

Am 06.12.2017 um 22:09 schrieb John Erling Blad:
> What is the current state, will some kind of digest be retained?

The current plan is to keep the SHA1 hash, one for each slot, and an aggregate
one for the revision. If there is only one slot, the revision hash is the same
as the slat hash.

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] Fwd: Re: [Wikidata] Imperative programming in Lua, do we really want it?

[Brian Wolff]

Lua is used for many purposes - some of which I think are well suited to an
imperaive approach (or at least would be totally fine to do in an
imperative style). There are of course many cases where an imperative
approach would be a poor choice.

There are no rules that apply to all programming things equally - context
of the programming task matters.

--
bawolff

On Thursday, December 7, 2017, mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:
> Following your message Jeroen, there it also is on Wikitech-l now.
>
>  Message transféré 
> Sujet : Re: [Wikidata] Imperative programming in Lua, do we
really want it?
> Date :  Wed, 6 Dec 2017 23:53:17 +0100
> De :Jeroen De Dauw 
> Répondre à :Discussion list for the Wikidata project. <
wikid...@lists.wikimedia.org>
> Pour :  Discussion list for the Wikidata project. <
wikid...@lists.wikimedia.org>
>
>
>
> Hey,
>
> While I am not up to speed with the Lua surrounding Wikidata or
MediaWiki, I support the call for avoiding overly imperative code where
possible.
>
> Most Lua code I have seen in the past (which has nothing to do with
MediaWiki) was very imperative, procedural and statefull. Those are things
you want to avoid if you want your code to be maintainable, easy to
understand and testable. Since Lua supports OO and functional styles, the
language is not an excuse for throwing well establishes software
development practices out of the window.
>
> If the code is currently procedural, I would recommend establishing that
new code should not be procedural and have automawted tests unless there is
very good reason to make an exception. If some of this code is written by
people not familiar with software development, it is also important to
create good examples for them and provide guidance so they do not
unknowingly copy and adopt poor practices/styles.
>
> John, perhaps you can link the code that caused you to start this thread
so that there is something more concrete to discuss?
>
> (This is just my personal opinion, not some official statement from
Wikimedia Deutschland)
>
> PS: I just noticed this is the Wikidata mailing list and not the
Wikidata-tech one :(
>
> Cheers
>
> --
> Jeroen De Dauw | https://entropywins.wtf |https://keybase.io/jeroendedauw
> Software craftsmanship advocate | Developer at Wikimedia Germany
> ~=[,,_,,]:3
>
> On 6 December 2017 at 23:31, John Erling Blad > wrote:
>
>With the current Lua environment we have ended up with an imperative
>programming style in the modules. That invites to statefull objects,
>which does not create easilly testable libraries.
>
>Do we have some ideas on how to avoid this, or is it simply the way
>things are in Lua? I would really like functional programming with
>chainable calls, but other might want something different?
>
>John
>
>___
>Wikidata mailing list
>wikid...@lists.wikimedia.org 
>https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

Hi!

Recently it seems as though there's been a huge increase in the use of
exceptions within the MediaWiki ecosystem. That's perfectly fine.
Exceptions are fantastic and a standard part of any developer's toolkit.

However, there seems to be a trend in throwing exceptions for codepaths
that don't catch them prior to returning to the user. The one I'm calling
out in particular is InvalidArgumentException.

It seems as though some code paths that are relying on user-generated input
are throwing this exception. That's pretty evil. There's a couple of
reasons:
-  This just returns a generic 503 error to our users. They don't know what
went wrong and they're left wondering why and filing bugs.
- Due to our current logging setup, we don't do nice parameter grouping for
exceptions. This means that each one is reported on its own, and we don't
have an idea of the scale/severity of the problem. We need to fix this, but
it doesn't preclude us being more proactive.

Basically the short version is: exceptions should only be shown to users in
the situation of *actual software errors*. They're the exception, not the
norm. What we *should* do in such situation is log the error (at the
ERROR/WARNING/etc level as appropriate) and then gracefully fall back.

I don't think we need an RfC or anything formal here, just a little bit of
common sense :)

Tldr: if there's no such user "Foo", we shouldn't return an exception when
a user tries to perform an action on it. We should return a helpful error
message, log it, and fall back gracefully.

-Chad

PS: Now that I think about it, there's been a proliferation of
RuntimeException for the exact same thing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Daniel Kinzler]

Am 07.12.2017 um 19:48 schrieb Chad:
> Basically the short version is: exceptions should only be shown to users in
> the situation of *actual software errors*. They're the exception, not the
> norm. What we *should* do in such situation is log the error (at the
> ERROR/WARNING/etc level as appropriate) and then gracefully fall back.

I agree with the idea, but I'd like to point out that log-and-fall-back should
*not* be the normal way to handle things, IMHO.

Let's take for example an invalid title. If a user supplied an invalid title,
they should get a helpful error. There is no reason to even log this, really.
This should be done by code that expects to handle user input, and can involve
throwing and catching exceptions, or be handled some other way.

Code that does not expect raw user input usually SHOULD thrown an
InvalidArgumentException if it gets invalid input, though! Something went wrong,
so we should fail fast & safe!

We should however improve how we show exceptions to users. We have "nicer"
handling for MWException than for other exceptions. I can think of no good
reason for this distinction - can't we do the nicer handling for all exceptions?

The log-and-fall-back case should be quite rare, and be reserved for
compatibility code - compatibility with old data, in particular. So perhaps the
invalid title comes from the page or the pagelinks table - that's unexpected,
but not impossible: someone may have fiddled with $wgLegalTitleChars, rendering
once-valid titles invalid. So in that case, log-and-fall-back is the correct
behavior.

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] Last Call: MediaWiki 1.30 Release Candidate 0

[Cindy Cicalese]

We are getting ready to release MediaWiki 1.30 - probably tomorrow. If you have 
found any bugs while testing Release Candidate 0, please report them now.

Thanks!

Cindy

__

Cindy Cicalese
Product Manager, MediaWiki Platform
Wikimedia Foundation

> Begin forwarded message:
> 
> From: Cindy Cicalese 
> Subject: Availability of MediaWiki 1.30 Release Candidate 0
> Date: November 28, 2017 at 10:23:53 PM EST
> To: mediawiki-annou...@lists.wikimedia.org
> 
> I would like to announce the immediate availability of MediaWiki 1.30.0-rc.0, 
> the first release candidate for 1.30.x. Links are at the end of this e-mail.
> 
> This is not a final release and should not be used for production websites.
> 
> As always, please do try out the release candidate in a test environment. 
> It's how we find bugs that didn't surface in initial development.
> 
> Barring any unforeseen issues, we hope to move forward to the release of 
> MediaWiki 1.30 in the next few weeks.
> 
> Per the version lifecycle, the current MediaWiki LTS version is 1.27.4. The 
> 1.27 LTS branch will continue to be supported through June 2019. The 1.29 
> branch is not an LTS branch, but it will continue to be supported until July 
> 2018. The current version in that branch is 1.29.2. MediaWiki 1.28.x reached 
> End of Life this month. The final release in this series was 1.28.3.
> 
> Full release notes: 
> https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_30/RELEASE-NOTES-1.30
> 
> **
> Download: 
> https://releases.wikimedia.org/mediawiki/1.30/mediawiki-1.30.0-rc.0.tar.gz
> GPG signature: 
> https://releases.wikimedia.org/mediawiki/1.30/mediawiki-1.30.0-rc.0.tar.gz.sig
>  (signed by Chad Horohoe)
> 
> Core only, no extensions: 
> https://releases.wikimedia.org/mediawiki/1.30/mediawiki-core-1.30.0-rc.0.tar.gz
> GPG signature: 
> https://releases.wikimedia.org/mediawiki/1.30/mediawiki-core-1.30.0-rc.0.tar.gz.sig
>  (signed by Chad Horohoe)
> 
> Public keys: https://www.mediawiki.org/keys/keys.html
> __
> Cindy Cicalese
> Product Manager, MediaWiki Platform
> Wikimedia Foundation


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

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

On Thu, Dec 7, 2017 at 11:07 AM Daniel Kinzler 
wrote:

> Am 07.12.2017 um 19:48 schrieb Chad:
> > Basically the short version is: exceptions should only be shown to users
> in
> > the situation of *actual software errors*. They're the exception, not the
> > norm. What we *should* do in such situation is log the error (at the
> > ERROR/WARNING/etc level as appropriate) and then gracefully fall back.
>
> I agree with the idea, but I'd like to point out that log-and-fall-back
> should
> *not* be the normal way to handle things, IMHO.
>
> Let's take for example an invalid title. If a user supplied an invalid
> title,
> they should get a helpful error. There is no reason to even log this,
> really.
> This should be done by code that expects to handle user input, and can
> involve
> throwing and catching exceptions, or be handled some other way.
>
>
We're on the same page here. It doesn't inherently need to be logged,
that's why I qualified it with "as appropriate." If it's something where
the user just typed something bogus, we should return a helpful error to
them and move on. And the emphasis in what you say here *really* needs to
be on CATCHING the exception. Throwing with no catch is what's evil :)


> Code that does not expect raw user input usually SHOULD thrown an
> InvalidArgumentException if it gets invalid input, though! Something went
> wrong,
> so we should fail fast & safe!
>
>
Indeed, I have no qualms with this. The point I'm making is on
user-generated actions.


> We should however improve how we show exceptions to users. We have "nicer"
> handling for MWException than for other exceptions. I can think of no good
> reason for this distinction - can't we do the nicer handling for all
> exceptions?
>
>
Because our exception handling code is crap. Nobody's had the cycles to
work on it. Volunteers welcome ;-)

MWException is *very* heavy weight, and sadly doesn't let us use native PHP
extensions that make more sense. InvalidArgumentException is descriptive,
MWException is not. And a MWInvalidArgumentException that extends
MWException just to be descriptive seems overkill.

In an ideal world: we don't need MWException at all, or else it becomes a
lightweight wrapper exception for any other type on demand. I'm thinking
something like

throw MWException( 'InvalidArgumentException' )

Who knows?


> The log-and-fall-back case should be quite rare, and be reserved for
> compatibility code - compatibility with old data, in particular. So
> perhaps the
> invalid title comes from the page or the pagelinks table - that's
> unexpected,
> but not impossible: someone may have fiddled with $wgLegalTitleChars,
> rendering
> once-valid titles invalid. So in that case, log-and-fall-back is the
> correct
> behavior.
>
>
Indeed. Not all bad behavior needs logging (or sometimes, just at a
DEBUG/INFO level because data is nice but yelling at log watchers is not).

Details all tbd, but I don't think you and I disagree here much at all :)

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

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Bartosz Dziewoński]

For "expected" exceptions, you can throw ErrorPageError or one of its 
subclasses, which is handled internally to produce a pretty user-facing 
error page.


--
Bartosz Dziewoński

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

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

On Thu, Dec 7, 2017 at 11:15 AM Bartosz Dziewoński 
wrote:

> For "expected" exceptions, you can throw ErrorPageError or one of its
> subclasses, which is handled internally to produce a pretty user-facing
> error page.
>
>
Yeah, and when you throw ErrorPageError deep enough in a code path, it can
explode on cli operations. I've seen this before.

Our MWException handling is weird :\

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

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Bartosz Dziewoński]

On 2017-12-07 21:05, Chad wrote:

Yeah, and when you throw ErrorPageError deep enough in a code path, it can
explode on cli operations. I've seen this before.


Indeed you did, you even fixed this bug a couple months ago ;)
I'm pretty sure it's safe to use now.

25c3c061b51cbfe377ebb2decbe09f7db7bc7397
https://gerrit.wikimedia.org/r/#/c/363660/

--
Bartosz Dziewoński

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

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

On Thu, Dec 7, 2017 at 12:24 PM Bartosz Dziewoński 
wrote:

> On 2017-12-07 21:05, Chad wrote:
> > Yeah, and when you throw ErrorPageError deep enough in a code path, it
> can
> > explode on cli operations. I've seen this before.
>
> Indeed you did, you even fixed this bug a couple months ago ;)
> I'm pretty sure it's safe to use now.
>
> 25c3c061b51cbfe377ebb2decbe09f7db7bc7397
> https://gerrit.wikimedia.org/r/#/c/363660/
>
>
Hacked so as to not explode. But the whole thing is a mess still.

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