[Wikitech-l] Extension! Re: Wikimedia Developer Satisfaction Survey - 2021!

2021-03-23 Thread Greg Grossmeier 
Good news!

The deadline to submit your answers to this year's Developer Satisfaction
Survey is extended!

You now have until next *Wednesday March 31st*!

Right now we're at about 60 responses. Last year we hit 75. Please fill
this out so we can continue improving!

Get your feedback in!

Thanks,

Greg

On Mon, Mar 8, 2021 at 9:54 AM Greg Grossmeier  wrote:

> Hello!
>
> tl;dr: It's time for the annual Developer Satisfaction Survey! *This
> survey is for everyone who uses any of the tools or services mentioned
> below*, whether you would call yourself a "developer" or not. *Closing
> date is March 24th.*
>
> *The survey*: https://forms.gle/xj2jNUcP7kmSgtwV8
>
> Longer:
> The Wikimedia Foundation is soliciting your feedback to measure developer
> satisfaction and determine where to invest resources in the future. This is
> the third iteration of this survey. We want feedback from everyone who uses
> any of the below tools or services, whether you call yourself a "developer"
> or not.
>
> Topics covered include:
> * Local Development Environment
> * Beta Cluster / Staging Environment
> * Testing / CI
> * Code Review
> * Deployments
> * Account Management and Onboarding
> * Observability
> * Phabricator
> * Developer documentation
> * General Feedback
>
> We are soliciting feedback from all Wikimedia developers, including Staff,
> 3rd party contributors and volunteer developers. *The survey will be open
> for a little over 2 weeks, closing on Wednesday March 24th.*
>
> NOTE: This survey will be conducted via a third-party service, which may
> be subject to additional terms. For more information on privacy and
> data-handling, see the survey privacy statement
> https://foundation.wikimedia.org/wiki/Developer_Satisfaction_Survey_Privacy_Statement
>
> *To participate in this survey, please start here:*
>
> https://docs.google.com/forms/d/e/1FAIpQLSfJCzxixT1wHCIgI5PijIMQvcIqDbsDTYbbDoxXaYcyF8RhJg/viewform?usp=sf_link
>
> Thank you for your participation,
>
> Greg
>
> --
> | Greg Grossmeier  GPG: B2FA 27B1 F7EB D327 6B8E |
> | Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
>


-- 
| Greg Grossmeier  GPG: B2FA 27B1 F7EB D327 6B8E |
| Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Train vs Backport for Wikimedia Deployment

2021-03-23 Thread Tyler Cipriani 
Hi!

On Tue, Mar 23, 2021 at 2:59 PM Kunal Mehta  wrote:

> > As with all things, some exceptions may apply. The Release Engineering
> > team has created some guidelines[0] that will hopefully help explain
> > when something MUST, SHOULD, or MAY[1] be deployed via the train or via
> > backport.
>
> Is this suppose to codify existing practice, or suggest/recommend people
> should be deploying things more frequently outside of the normal train?
> Tgr has raised roughly the same question on the talk page:
> .
>

Arg! Missed that there was discussion there :(

I'll follow-up here and try to answer the additional questions there as
well.

The intent of this page is to encourage more deployments outside of the
normal train by developers and code authors.

This page was meant to make clear the types of changes that would be
difficult to deploy outside of the train for historical reasons, and to
encourage the authors of other types of patches to consider deploying the
change themselves or with a deployer in a backport window.

There are a few reasons that releng wants to encourage backports:
1. Smaller deployments are easier to reason about
2. The code author is often in the best position to reason the effect of
their changes
3. The use of mwdebug as a manual testing platform, while similar to the
group-by-group rollout of the train, can ensure that a change is working on
several wikis in multiple groups with no impact to users.

Not every patch can be backported (just due to hours/day -- 420 changes
this train[0] -- 5 minute deploy each is 35 hours of deploying), also
backport windows are finite, and deployers time is limited. With those
constraints in mind, we'd still like to move to a more continuous model of
delivery and the hope is that these guidelines are a step in that
direction. I'm also open to other ideas about ways to make the train a
lighter and more consistent process.

Thanks!
-- Tyler

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

Re: [Wikitech-l] Train vs Backport for Wikimedia Deployment

2021-03-23 Thread Kunal Mehta 

Hi,

On 3/18/21 1:49 PM, Tyler Cipriani wrote:
Over time The Train™ has become the default way to deploy changes to 
Wikimedia's MediaWiki cluster -- for some patches that may not always be 
the right path. If a developer needs a change deployed *now*, or if 
there is a desire to deploy a change in isolation then backports might 
be a better path.


As with all things, some exceptions may apply. The Release Engineering 
team has created some guidelines[0] that will hopefully help explain 
when something MUST, SHOULD, or MAY[1] be deployed via the train or via 
backport.


Is this suppose to codify existing practice, or suggest/recommend people 
should be deploying things more frequently outside of the normal train? 
Tgr has raised roughly the same question on the talk page: 
.


Thanks,
-- Legoktm

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

Re: [Wikitech-l] Maps Modernization plan - FYI

2021-03-23 Thread Seve Kim 
Hi Strainu,

I am a Product Manager at WMF. To answer your question, the Maps
Modernization effort doesn't interact much with the WMDE planned
improvements that you mentioned.

The Maps Modernization plan addresses more infrastructure needs.
With its completion, it will provide the maintainers of the maps
infrastructure with better monitoring, as an example. This will help better
prevent and address outages and ensure the reliability of maps as a service.

I believe the WMDE improvements are more client-facing or user-facing
needs. Things like allowing for users to save their default map view or
better interactive maps. WMF has kept in contact with the Technical Wishes
team but I believe this work does not directly impact the planned
improvements.

Best,
Seve

On Mon, Mar 22, 2021 at 2:01 PM Strainu  wrote:

> Hi Erica,
>
> Thanks for the announcement, I'm glad to see some love given to Maps.
> Could you explain how this initiative interacts with the planned
> improvements from WMDE [3]?
>
> Thank you,
>Strainu
>
> [3] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation
>
>
> În lun., 22 mar. 2021 la 19:11, Erica Litrenta 
> a scris:
>
>> Greetings,
>>
>> This is a follow up from our last email some months ago (and a
>> crosspost). You may already have seen today's announcement from Legal about
>> the upcoming changes to the Maps Terms of Use. Here is an extra heads-up
>> that Wikimedia Maps are transitioning towards a more modern
>> architecture. The first phase of this transition will be replacing
>> Tilerator [0] with Tegola [1] as our vector tile server. This is a change
>> in the Maps infrastructure, so there should be little to no impact to the
>> end users’ experience.
>>
>> It is important that we are able to provide software that is sustainable
>> to support, before we can guarantee a reliable user experience. Wikimedia
>> Maps aim to provide Wikimedia users a consistent experience contributing to
>> and learning about geoinformation. To achieve this goal, we will empower
>> those engineers maintaining the Wikimedia Maps infrastructure to do so with
>> ease and low effort.
>>
>> If you want to learn more, please head to mediawiki.org [2], where you
>> will also find a Questions & Answers section.
>>
>> Thanks, and take care,
>>
>> Erica Litrenta (on behalf of the Product Infrastructure team)
>>
>> [0] https://wikitech.wikimedia.org/wiki/Maps/Tilerator
>>
>> [1] https://tegola.io/
>> [2] https://www.mediawiki.org/wiki/Wikimedia_Maps/2021_modernization_plan
>>
>> --
>>
>> --
>>
>>
>> Erica Litrenta (she/her)
>>
>> Manager, Community Relations Specialists
>>
>> Wikimedia Foundation 
>>
>> ___
>> 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
>


-- 

*Seve Kim* *(he/him)*
Product Manager, Platform
Wikimedia Foundation 

*   Wikipedia turns 20!
*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] eqiad kubernetes cluster upgrade on 2021-03-23

2021-03-23 Thread Alexandros Kosiaris 
Hello everyone,

This has happened. The cluster has been reinitialized and upgraded and
all services have been redeployed by SRE Service Operations. So, the
cluster is fully operational again, feel free to deploy. Traffic
hasn't been switched yet back as we are still making sure that it's
also fully traffic capable as well, but it's expected to happen at the
latest tomorrow.

On Tue, Mar 23, 2021 at 10:23 AM Alexandros Kosiaris
 wrote:
>
> Hello everyone,
>
> This is starting now. Keep in mind that if you try to deploy to eqiad
> k8s today, it WILL fail or just won't do what you expect it to do.
>
> On Fri, Mar 19, 2021 at 10:02 PM Alexandros Kosiaris
>  wrote:
> >
> > Hello everyone,
> >
> > TL;DR if you are not deploying services to the eqiad kubernetes
> > cluster, you can safely skip this.
> >
> > Long version:
> >
> > After having tested thrice our cluster reinitialization procedure, next
> > week, on Tuesday 2021-03-23 we will be reinitializing our eqiad
> > kubernetes cluster. All
> > traffic will be drained from it beforehand and we expect no user
> > visible impact. However, for the duration of the process, the
> > kubernetes eqiad cluster will be unavailable to deployers and thus
> > efforts to deploy to it will fail or worse, not have the expected
> > outcomes. This is normal until SRE serviceops announces that the
> > cluster is fully operational again.
> >
> > SRE service-ops will be deploying all services before marking the
> > cluster as usable and pooling traffic back to it, so there will be no
> > need for deployers to re-deploy their services.
> >
> > For your convenience the list of services that are currently deployed
> > on that cluster is: apertium api-gateway blubberoid changeprop
> > changeprop-jobqueue citoid cxserver echostore eventgate-analytics
> > eventgate-analytics-external eventgate-logging-external eventgate-main
> > eventstreams eventstreams-internal linkrecommendation mathoid
> > mobileapps proton push-notifications recommendation-api sessionstore
> > similar-users termbox wikifeeds zotero
> >
> > Regards,
> >
> > --
> > Alexandros Kosiaris
> > Principal Site Reliability Engineer
> > Wikimedia Foundation
>
>
>
> --
> Alexandros Kosiaris
> Principal Site Reliability Engineer
> Wikimedia Foundation



-- 
Alexandros Kosiaris
Principal Site Reliability Engineer
Wikimedia Foundation

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

Re: [Wikitech-l] Joining Trusted-Contributors

2021-03-23 Thread Klaas Skelte van der Werf 
I've managed to amend 
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/674149, 
so this works now.
Thank you very much!

Mainframe98


Van: Wikitech-l  namens Zoran Dori 

Verzonden: dinsdag 23 maart 2021 09:55
Aan: For developers discussing technical aspects and organization of Wikimedia 
projects 
Onderwerp: Re: [Wikitech-l] Joining Trusted-Contributors

Hello,
I've done it now because you are in the same group on Phabricator. I believe 
that it isn't a problem for others.

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

Re: [Wikitech-l] Joining Trusted-Contributors

2021-03-23 Thread Zoran Dori 
Hello,
I've done it now because you are in the same group on Phabricator. I
believe that it isn't a problem for others.

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

[Wikitech-l] Joining Trusted-Contributors

2021-03-23 Thread Klaas Skelte van der Werf 
I just noticed that I can no longer amend other peoples patch sets. I used to 
have this ability, but it appears that it was moved to Trusted-Contributors. 
[1] Can someone in that group add me?

Thanks in advance.

Mainframe98

[1] https://phabricator.wikimedia.org/T238651

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

Re: [Wikitech-l] eqiad kubernetes cluster upgrade on 2021-03-23

2021-03-23 Thread Alexandros Kosiaris 
Hello everyone,

This is starting now. Keep in mind that if you try to deploy to eqiad
k8s today, it WILL fail or just won't do what you expect it to do.

On Fri, Mar 19, 2021 at 10:02 PM Alexandros Kosiaris
 wrote:
>
> Hello everyone,
>
> TL;DR if you are not deploying services to the eqiad kubernetes
> cluster, you can safely skip this.
>
> Long version:
>
> After having tested thrice our cluster reinitialization procedure, next
> week, on Tuesday 2021-03-23 we will be reinitializing our eqiad
> kubernetes cluster. All
> traffic will be drained from it beforehand and we expect no user
> visible impact. However, for the duration of the process, the
> kubernetes eqiad cluster will be unavailable to deployers and thus
> efforts to deploy to it will fail or worse, not have the expected
> outcomes. This is normal until SRE serviceops announces that the
> cluster is fully operational again.
>
> SRE service-ops will be deploying all services before marking the
> cluster as usable and pooling traffic back to it, so there will be no
> need for deployers to re-deploy their services.
>
> For your convenience the list of services that are currently deployed
> on that cluster is: apertium api-gateway blubberoid changeprop
> changeprop-jobqueue citoid cxserver echostore eventgate-analytics
> eventgate-analytics-external eventgate-logging-external eventgate-main
> eventstreams eventstreams-internal linkrecommendation mathoid
> mobileapps proton push-notifications recommendation-api sessionstore
> similar-users termbox wikifeeds zotero
>
> Regards,
>
> --
> Alexandros Kosiaris
> Principal Site Reliability Engineer
> Wikimedia Foundation



-- 
Alexandros Kosiaris
Principal Site Reliability Engineer
Wikimedia Foundation

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