Re: [Wikitech-l] New Gerrit privilege policy

[Merlijn van Deen (valhallasw)]

On Sat, 16 Mar 2019 at 03:01, Tim Starling  wrote:

> No, managing +2 permissions is not up to the maintainer of the tool,
> that's the whole point of the change.
>

I feel that this policy, although well-meaning, and a step forwards for
MediaWiki and other WMF-production software, is unreasonably being applied
as a 'one-size-fits-all' solution to situations where it doesn't make sense.

Two examples where the policy does not fit the Toolforge situation:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.

2. Giving someone +2 access to a repository now needs to pass through an
extended process with checks and balances. At the same time, I can *directly
and immediately give someone deployment access to the tool.*

Effectively, this policy forces me to move any tool repositories off Gerrit
and onto GitHub: time and effort better spent otherwise.

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Merlijn van Deen (valhallasw)]

On Fri, 18 Jan 2019 at 07:58, Giuseppe Lavagetto 
wrote:

> The amount of noise will prevent me from being able to notice anyone's
> review request. I think it's going to be the same for other developers - I
> don't want to imagine what the inbox of a long-time mediawiki-core
> contributor must look like!
>
> What I fear is that the flood of reviews will make everyone just dull to
> notifications, obtaining the exact opposite effect that was intended. I say
> this because  I auto added myself to all reviews in operations/puppet[1] in
> the past, which resulted in me ignoring all code review requests.
>
>
Reading this thread -- and Guiseppes comment above in particular, made me
think a bit on how we do code review, and how automatically adding
reviewers may be counterproductive. This includes the Gerrit Reviewer Bot:
even though it is opt-in, it may still overwhelm the inbox of whoever opted
in, and if that person does not unsubscribe (but rather creates a filter to
move all the requests into a 'I don't have time to look at this now, but I
will review these later' mailbox - I have done this myself at some point,
which meant that in practice, I didn't review anything for that project
anymore), we end up in a situation where code is not actually reviewed in a
more timely manner.

One thing I wondered about is how big the problem of patches without
relevant reviewers is. This is not entirely trivial to query, but the best
I could come up with was looking for patches without any reviewer at all:
https://gerrit.wikimedia.org/r/q/status:open+-reviewerin:%2522Registered+Users%2522
. This is only a very small number of patches -- while the number of
patches that have V+1 CR=0 Age > 1 month is much larger:
https://gerrit.wikimedia.org/r/q/status:open+label:Verified%253E%253D0+label:Code-Review%253D0+age:1month

This suggests to me that the problem is not a lack of reviewers added, but
a lack of reviewing :-). This might be due to the wrong reviewers being
added (which an improved version of the auto-reviewer plugin could solve),
but it might also just be that the reviewers don't have enough time to
actually perform the reviews. That includes myself -- I find it very
difficult to get started doing reviews on code I haven't looked at a while.
After all, it's much more fun to write code than to review it ;-)

How to solve that? I don't know -- I think initiatives such as Andre's
'Patchsets by new Gerrit contributors' emails help (as they focus on a
small number of changes). The same is true for a form of gamification (such
as the statistics in the previous Thank You day threads).

In general, I believe that trying something new (which includes trying the
Gerrit plugin!) is going to be beneficial, as otherwise we never discover
which directions improve things (and which ones don't). After all, the
Reviewer Bot is already 8 years old, and it's unlikely that the thing I
hacked together back then is still the best solution now :-)

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

Re: [Wikitech-l] Public Event Streams (AKA RCStream replacement) question

[Merlijn van Deen (valhallasw)]

Hi Andrew,

On 23 September 2016 at 23:15, Andrew Otto  wrote:

> We’ve been busy working on building a replacement for RCStream.  This new
> service would expose recentchanges as a stream as usual, but also other
> types of event streams that we can make public.
>

First of all, why does it need to be a replacement, rather than something
that builds on existing infrastructure? Re-using the existing
infrastructure provides a much more convenient path for consumers to
upgrade.


> But we’re having a bit of an existential crisis!  We had originally chosen
> to implement this using an up to date socket.io server, as RCStream also
> uses socket.io.  We’re mostly finished with this, but now we are taking a
> step back and wondering if socket.io/websockets are the best technology to
> use to expose stream data these days.
>

For what it's worth, I'm on the fence about socket.io. My biggest argument
for socket.io is the fact that rcstream already uses it, but my experience
with implementing the pywikibot consumer for rcstream is that the Python
libraries are lacking, especially when it comes to stuff like reconnecting.
In addition, debugging issues requires knowledge of both socket.io and the
underlying websockets layer, which are both very different from regular
http.

From the task description, I understand that the goal is to allow easy
resumation by passing information on the the last received message. You
could consider not implementing streaming /at all/, and just ask clients to
poll an http endpoint, which is much easier to implement client-side than
anything streaming (especially when it comes to handling disconnects).

So: My preference would be extending the existing rcstream framework, but
if that's not possible, my preference would be with not streaming at all.

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

Re: [Wikitech-l] Phab blogs

[Merlijn van Deen (valhallasw)]

On 18 May 2016 at 07:39, Amir E. Aharoni 
wrote:

> I couldn't find a way to subscribe to them in RSS. Is it possible?
>

I also can't find the button, but there is a magic trick. Change

https://phabricator.wikimedia.org/phame/blog/view/5/

into

https://phabricator.wikimedia.org/phame/blog/feed/5/

and you get the corresponding atom feed.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l