Re: [Wikitech-l] Module storage is coming

[John Erling Blad]

Can you explain why you use LocalStorage for this? It seems to me like
this is the wrong solution and you should use cache manifests instead.
LocalStorage is a quite limited area for _data_ storage and it will
create problems if we start wasting that space for _code_ storage.

John

On Mon, Nov 4, 2013 at 2:27 AM, Ori Livneh  wrote:
> The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
> inaugurate the era of ResourceLoader module storage -- an era which
> will be marked by terrifying and hilarious new bugs, intermittent
> client-side failures, and generally inexcusable disruptions to user
> experience. Sounds exciting? Read on!
>
> What is it?
> ---
> "Module storage" refers to the use of localStorage in ResourceLoader
> as an auxiliary to the browser cache. ResourceLoader, remember, is the
> MediaWiki subsystem that delivers JavaScript and CSS to your browser.
> One of its primary functions is to minimize the total number of
> network requests that your browser needs to make in order to render
> the page, and to make the remaining requests as slim as possible. One
> of the ways ResourceLoader does this is by making a list of all the
> different components your browser needs and then transmitting them in
> bulk.
>
> The downside of this approach is that a small update to MediaWiki's
> code, touching perhaps one or two components, will often force the
> browser to throw out (and re-retrieve) a bunch of unrelated modules
> that did not change and did not ostensibly need to be re-retrieved.
> This is because the browser cache operates on the level of network
> requests; it is not intelligent enough to decompose a request into its
> constituitive parts and to cache these parts separately from one
> another.
>
> Starting with the 1.23wmf2 branch, ResourceLoader will check if your
> browser implements localStorage, a mechanism for storing structure
> data. If it does, ResourceLoader will use it as an auxiliary cache,
> capable of versioning individual components.
>
> Why?
> 
> The primary goals are:
>
> * Destabalize MediaWiki's front-end code, by coupling it to an
> inconsistently-implemented and poorly-understood HTML5 API.
> * Make debugging fun again, by adding another layer of caching to
> MediaWiki. Yes!!
>
> However, as with all new features, unintended side-effects are
> possible. Specific concerns for module storage include the risk of
> making the network footprint of page loads smaller, resulting in
> improved latency.
>
> But seriously,
> --
> * Module storage is enabled only if the underlying browser supports
> localStorage (~89% of browsers in use, according to
> ). Users with older
> browsers will not see a benefit, but they will not suffer a penalty
> either.
> * Module storage may or may not improve site performance. We need to
> test it against a wide range of browsers and platforms to know for
> certain. If it  doesn't improve performance, we'll blame it on you,
> your poor choice of browsers, and your uncooperative attitude, but
> then we'll scrap it.
>
> How can I test it?
> --
> Glad you asked! Module storage is enabled by default on the beta
> cluster, and on test & test2 wikis. The simplest way you can help is
> by being alert to to performance regressions and front-end code
> breakage. If you know how to use your browser's JavaScript console,
> you can get stats about module storage usage on the current page by
> checking the value of 'mw.loader.store.stats'.
>
> When the code is rolled out across the cluster, it will be disabled by
> default, but you will be able to opt-in by manually setting a cookie
> in your browser. I will follow up with the exact details. If module
> storage proves stable enough for production use, we'll seek to asses
> its utility by running a controlled study of some kind. If we can
> demonstrate that module storage leads to a significant improvement in
> performance, we'll enable by it default.
>
> ---
> Ori Livneh
> o...@wikimedia.org
>
> ___
> 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] Architecture RFC review meeting, Nov 6

[Steven Walling]

On Wed, Nov 6, 2013 at 3:18 PM, Quim Gil  wrote:

> We just finished the meeting, and you can find the notes at
>
>
> http://integration-meetbot.instance-proxy.wmflabs.org/wikimedia-meetbot/2013/wikimedia-meetbot.2013-11-06-22.03.html
>
> We discussed TitleValue, Configuration database, and Password
> requirements. We didn't have time to review Allow styling in
> templates.
>

I wasn't able to make the meeting, but about the action item for Password
requirements, where Tim said, "what I would like from this RFC is for the
discussion to be moved out to the talk page"

Agreed. I can try to help do this, if Chris or someone hasn't already. In
general it seems like this RFC is conceptually pretty simple but just needs
some word-smithing.

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

Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?

[Daniel Friesen]

On 2013-10-27 8:04 PM, Isarra Yos wrote:
> I found this to be a good part why arial was so damn unreadable on my
> linux setup, for instance, though even with it rendering properly now
> it's still narrower than I find comfortable as well. Perhaps this is
> just because I'm used to wider, but going against what people are used
> to (and thus have effectively trained their brains upon), or
> especially what they might have specifically customised (in particular
> large or dyslexic fonts come to mind as a specific usability issue
> here), also seems like an odd move.
>
> And yes, I know it's a standard move that websites tend to make. It's
> still odd, and I can't say I like that folks are trying to take
> mediawiki/wikimedia in a similar direction, even without the question
> of whether or not the specifics are free or not.
Actually I read something related recently:
http://www.64notes.com/design/stop-helvetica-arial/

I started experimenting with browsing Wikipedia using 'Open Sans',
Verdana, sans-serif; and a less black text color (ie: lower black-white
contrast).
https://en.wikipedia.org/wiki/User:Dantman/vector.css



... Btw, I've also been experimenting with a script that uses
history.replaceState to fix the title on redirect pages for quite some
time now.
https://en.wikipedia.org/wiki/User:Dantman/vector.js

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] Module storage is coming

[Daniel Friesen]

Cache manifests are extremely inflexible. The HTTP caching we already
have is more flexible than cache manifests. So cache manifests won't
help make any improvements.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 2013-11-07 12:19 AM, John Erling Blad wrote:
> Can you explain why you use LocalStorage for this? It seems to me like
> this is the wrong solution and you should use cache manifests instead.
> LocalStorage is a quite limited area for _data_ storage and it will
> create problems if we start wasting that space for _code_ storage.
>
> John

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Faidon Liambotis]

On Tue, Nov 05, 2013 at 05:57:31PM -0800, Erik Moeller wrote:

So how should this role evolve going forward? Some possible paths (you
know I like to present options ;-):


The "architect" title, besides the job description that you described, 
is also a seniority level within the WMF's engineering department.  
Other organizations do e.g.  "sr./staff/sr. staff" and/or numeric 
levels, we do "associate / (blank) / sr. / (lead) architect". At least 
that's my understanding of what was presented during the last all-staff 
and documented on officewiki.


What would happen to this seniority level, if any of the options you 
presented were to be adopted? You seem to hint that there would be a 
mapping with option D ("salary increases") but it's not clear to me how 
direct of a mapping or a prerequisite would that be.


I don't think it'd reasonable to say that we have, as an organization 
with ~180 FT staff, a peer review process, an HR department, managers, 
directors & VPs *but* you can't be promoted inside the organization 
until an open community process says so (or, in case of option A, *at 
all*). It'd be even more illogical considering that currently no other 
positions exist where there is such a connection: this hasn't been the 
case for promotions to Sr. -- and, even in the leadership track, there 
have been promotions to managers, directors & VPs, with no such open 
community process.


If that's not the intention, on the other hand, I think it's useful to 
either hear WMF management's views on that or, if it is up for 
discussion, have this discussion in parallel with this one.


Whether we like it or not, the existing title has *two* meanings as it 
is —and my understanding is that the salary aspect came first, too— and 
I don't think we can have a meaningful discussion for the one without 
knowing the implications for the other.


Regards,
Faidon

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

Re: [Wikitech-l] Module storage is coming

[Jon Robson]

From personal experience don't touch cache manifests with a barge pole...

Bear in mind the majority of browsers provide at least 5mb of local storage
and we are talking about caching a few kB at most of minified JavaScript
On 7 Nov 2013 00:35, "Daniel Friesen"  wrote:

> Cache manifests are extremely inflexible. The HTTP caching we already
> have is more flexible than cache manifests. So cache manifests won't
> help make any improvements.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
> On 2013-11-07 12:19 AM, John Erling Blad wrote:
> > Can you explain why you use LocalStorage for this? It seems to me like
> > this is the wrong solution and you should use cache manifests instead.
> > LocalStorage is a quite limited area for _data_ storage and it will
> > create problems if we start wasting that space for _code_ storage.
> >
> > John
>
> ___
> 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] Architecture RFC review meeting, Nov 6

[Chris Steipp]

On Nov 7, 2013 12:29 AM, "Steven Walling"  wrote:
>
> On Wed, Nov 6, 2013 at 3:18 PM, Quim Gil  wrote:
>
> > We just finished the meeting, and you can find the notes at
> >
> >
> >
http://integration-meetbot.instance-proxy.wmflabs.org/wikimedia-meetbot/2013/wikimedia-meetbot.2013-11-06-22.03.html
> >
> > We discussed TitleValue, Configuration database, and Password
> > requirements. We didn't have time to review Allow styling in
> > templates.
> >
>
> I wasn't able to make the meeting, but about the action item for Password
> requirements, where Tim said, "what I would like from this RFC is for the
> discussion to be moved out to the talk page"
>
> Agreed. I can try to help do this, if Chris or someone hasn't already. In
> general it seems like this RFC is conceptually pretty simple but just
needs
> some word-smithing.

That would be really helpful! I'll add in the reset stuff soon too.

>
> Steven
> ___
> 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] Module storage is coming

[C. Scott Ananian]

What should I be aware of as a developer?  That is, if I'm running a local
MW and hacking on a resources (an extension / JavaScript / etc) will things
Just Work?  Or should I take active steps to disable Module Storage so that
I don't inadvertently run the 'old' version of something I'm hacking on?

From what I understand, it's currently disabled by default, etc, so I don't
have to worry yet.  But I guess I'm asking in advance to ensure that it's
well documented by the time we actually turn this on by default and
developers have to think about it.
 --scott


On Sun, Nov 3, 2013 at 8:27 PM, Ori Livneh  wrote:

> The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
> inaugurate the era of ResourceLoader module storage -- an era which
> will be marked by terrifying and hilarious new bugs, intermittent
> client-side failures, and generally inexcusable disruptions to user
> experience. Sounds exciting? Read on!
>
> What is it?
> ---
> "Module storage" refers to the use of localStorage in ResourceLoader
> as an auxiliary to the browser cache. ResourceLoader, remember, is the
> MediaWiki subsystem that delivers JavaScript and CSS to your browser.
> One of its primary functions is to minimize the total number of
> network requests that your browser needs to make in order to render
> the page, and to make the remaining requests as slim as possible. One
> of the ways ResourceLoader does this is by making a list of all the
> different components your browser needs and then transmitting them in
> bulk.
>
> The downside of this approach is that a small update to MediaWiki's
> code, touching perhaps one or two components, will often force the
> browser to throw out (and re-retrieve) a bunch of unrelated modules
> that did not change and did not ostensibly need to be re-retrieved.
> This is because the browser cache operates on the level of network
> requests; it is not intelligent enough to decompose a request into its
> constituitive parts and to cache these parts separately from one
> another.
>
> Starting with the 1.23wmf2 branch, ResourceLoader will check if your
> browser implements localStorage, a mechanism for storing structure
> data. If it does, ResourceLoader will use it as an auxiliary cache,
> capable of versioning individual components.
>
> Why?
> 
> The primary goals are:
>
> * Destabalize MediaWiki's front-end code, by coupling it to an
> inconsistently-implemented and poorly-understood HTML5 API.
> * Make debugging fun again, by adding another layer of caching to
> MediaWiki. Yes!!
>
> However, as with all new features, unintended side-effects are
> possible. Specific concerns for module storage include the risk of
> making the network footprint of page loads smaller, resulting in
> improved latency.
>
> But seriously,
> --
> * Module storage is enabled only if the underlying browser supports
> localStorage (~89% of browsers in use, according to
> ). Users with older
> browsers will not see a benefit, but they will not suffer a penalty
> either.
> * Module storage may or may not improve site performance. We need to
> test it against a wide range of browsers and platforms to know for
> certain. If it  doesn't improve performance, we'll blame it on you,
> your poor choice of browsers, and your uncooperative attitude, but
> then we'll scrap it.
>
> How can I test it?
> --
> Glad you asked! Module storage is enabled by default on the beta
> cluster, and on test & test2 wikis. The simplest way you can help is
> by being alert to to performance regressions and front-end code
> breakage. If you know how to use your browser's JavaScript console,
> you can get stats about module storage usage on the current page by
> checking the value of 'mw.loader.store.stats'.
>
> When the code is rolled out across the cluster, it will be disabled by
> default, but you will be able to opt-in by manually setting a cookie
> in your browser. I will follow up with the exact details. If module
> storage proves stable enough for production use, we'll seek to asses
> its utility by running a controlled study of some kind. If we can
> demonstrate that module storage leads to a significant improvement in
> performance, we'll enable by it default.
>
> ---
> Ori Livneh
> o...@wikimedia.org
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Quim Gil]

On 11/06/2013 04:24 PM, MZMcBride wrote:
> Quim Gil wrote:
>> On 11/06/2013 07:24 AM, Petr Bena wrote:
>>> So that's why suddenly I started receiving these email requests :D
>>
>> No, you are getting suddenly these emails from a group of students at
>> http://foss.amrita.ac.in because a mentor told them to do so. We have
>> explained the right process to them (asking in the bug report itself
>> instead of sending private emails).
> 
> This makes no sense to me. The issue is the extra step altogether.

The issue is the extra step for newcomers vs the risk of many extra
steps for a few etablished contributors if someone decides to abuse the
feature, as it happened in the past. And my point is that I personally
don't believe that such barrier is diminishing the volume of actual
contributions we receive.

In order to get somewhere with this discussion, it would be useful to
know the current practice of other free software projects, using
Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME,
KDE, Ubuntu, Debian... etc?

For what is worth the Bugzilla mainainers decided to set the extra step
by default and they were puzzled when RobLa told them that we had
removed it in our big project.

-- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Chad]

On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier  wrote:

> I like the idea of giving everyone who has editbugs the right to give
>  other people the editbugs permission.  That's certainly worth a try
> assuming it's possible to configure.
>
>
I want to underscore this again. I think this is a great idea
and I haven't seen any objections to it yet. Can we go ahead
with this proposal?

(Even if we go further, this is a nice first step imho)

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Bartosz Dziewoński]

On Thu, 07 Nov 2013 17:33:14 +0100, Chad  wrote:


On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier  wrote:


I like the idea of giving everyone who has editbugs the right to give
 other people the editbugs permission.  That's certainly worth a try
assuming it's possible to configure.



I want to underscore this again. I think this is a great idea
and I haven't seen any objections to it yet. Can we go ahead
with this proposal?


This sounds like a great compromise. Please make it happen!


--
Matma Rex

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

Re: [Wikitech-l] Module storage is coming

[Chris McMahon]

On Thu, Nov 7, 2013 at 8:05 AM, Jon Robson  wrote:

> From personal experience don't touch cache manifests with a barge pole...
>
> Bear in mind the majority of browsers provide at least 5mb of local storage
> and we are talking about caching a few kB at most of minified
> JavaScript
> On 7 Nov 2013 00:35, "Daniel Friesen"  wrote:
>

What I'm seeing in Chromium/Chrome is that when I invoke VisualEditor one
time localStorage hits ~3.5MB immediately.

Hit shift-reload a few times in quick succession and it's pretty easy to
max out localStorage for Chromium at 5.xMB.  Default for Chrome seems to be
10MB.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[C. Scott Ananian]

On Wed, Nov 6, 2013 at 10:13 AM, Brion Vibber  wrote:

> * However, I would consider avoiding using the term "Architect" for its
> members as it's easily conflated with existing WMF job titles. I think job
> titles are pretty unreliable indicators at the best of times, and of course
> can be wildly inconsistent across companies.
>
[...]

> As such, I'd recommend a slightly more formal role for additional "lead
> reviewers" or "module owners" in the code review & RFC processes; not as
> *gatekeepers* so much as to provide a next-step for getting something
> moving that's stalled -- a potential contributor or a team within WMF
> working on a feature should be able to easily determine who to talk to
> about getting a go/no-go or advice on what to do in case of a no-go.
>

My thoughts were similar.  I thought it might be useful to have a hierarchy
of 'architects'.  If there are 20 architects, then maybe it doesn't seem
like such a big deal.  (And maybe they shouldn't be called 'architects' but
rather 'module owners'.)

Basically, every major piece of WP should have a module owner.  For
example, gwicke owns Parsoid.  Maybe at some point he gets bored and moves
on to something else, and names someone else the module owner.  (That
shouldn't involve any adjustment to WMF salary!)

Certain people 'own' larger collections of modules -- like there are
subsystem owners in the linux kernel dev world.  For example, ideally there
should be someone who owns "the WMF deployed mediawiki" who can weigh in on
changes which affect the configuration and collection of modules which
actually constitute wikipedia.  And then there are the big three
("architects") who are really just the top-level module owners (the Linus
Torvalds, if you will).

I guess what I'm really proposing is subdividing the architectural
responsibility further, so that the BDFLs can delegate to the appropriate
"subsystem maintainers" more often.  Their jobs should mostly be selecting
trusted lieutenants, and signing off on the decisions of the lieutenants.
 The fact that they are currently so overworked means that we haven't
really delegated enough authority (or found enough trusted people?).

So I guess I'm in favor of getting rid of the "Architect" title and
replacing it with a more aggressive and hierarchical use of "Module Owner"
(and co-owner).  WMF may use the fact that historically someone has been a
trusted module owner in setting salary, but handing off ownership should be
something *encouraged* not penalized by a salary cut.  (If Tim ever wanted
to go off and work on a skunkworks project for a while, he should be able
to temporarily take off his 'Architect' hat without consulting HR and
losing salary.)
  --scott

ps. in the linux-kernel world, "subsystem maintainer" is an excellent title
to put on your resume.  I don't think we need to be hung up too much on the
particular word "architect".  We can invent a "Senior Fellow" or some such
title if we need to for HR reasons.  Let's not conflate technical
leadership with salary negotiation.  In a meritocracy the former will
always precede the latter; we should try to make sure that HR appropriately
recognizes the evolving technical situation without unnecessary delay,
rather than putting the cart before the horse.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Quim Gil]

On 11/07/2013 08:40 AM, C. Scott Ananian wrote:
> I thought it might be useful to have a hierarchy
> of 'architects'.  If there are 20 architects, then maybe it doesn't seem
> like such a big deal.  (And maybe they shouldn't be called 'architects' but
> rather 'module owners'.)
> 
> Basically, every major piece of WP should have a module owner.  For
> example, gwicke owns Parsoid.  Maybe at some point he gets bored and moves
> on to something else, and names someone else the module owner.  (That
> shouldn't involve any adjustment to WMF salary!)

Is your proposal different from
https://www.mediawiki.org/wiki/Developers/Maintainers ?

-- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Isarra Yos]

On 07/11/13 16:28, Quim Gil wrote:

The issue is the extra step for newcomers vs the risk of many extra
steps for a few etablished contributors if someone decides to abuse the
feature, as it happened in the past. And my point is that I personally
don't believe that such barrier is diminishing the volume of actual
contributions we receive.

In order to get somewhere with this discussion, it would be useful to
know the current practice of other free software projects, using
Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME,
KDE, Ubuntu, Debian... etc?


Would that be useful, though? Generally what other free software 
projects do is what works for them, and it won't necessarily work for 
us. It is also most especially not necessarily good practice when it 
comes to actually attracting and keeping new folks, simply due to the 
nature of what free software often entails - somewhere along the line, 
there is usually a lack of resources, and it is newcomers who suffer the 
most.


As much as projects would like, and for that matter, need, new folks, 
they only have so much time to devote to it and especially when 
volunteers make up a bulk of the community people wind up spending most 
time on other things. Bugzilla lacks certain key features that would 
make it feasible to open up from the start, and my guess would be it has 
something to do with similar - it was simply not a priority, so it never 
happened.


For a rather extreme example, there was another project, some OS thing, 
that a friend of mine wanted to contribute to awhile back, but he found 
that they had disabled account creation entirely due to lack of 
resources to combat spam, requiring instead that you find them on IRC or 
some such and contact them that way for an account. In no way is this 
good practice, and has very much harmed them as well, and yet it was 
probably the best thing they could do with what they had.


Just please be careful when looking at what other people do, here. Why 
they did something can be far more important than what they actually did.


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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[C. Scott Ananian]

On Thu, Nov 7, 2013 at 11:44 AM, Quim Gil  wrote:

> Is your proposal different from
> https://www.mediawiki.org/wiki/Developers/Maintainers ?
>

No, it builds on it.  The current wiki page isn't official, nor complete.
 I'm suggesting that we embrace it officially, and that we further add
additional hierarchical "modules" as needed to fill in the gap between the
big three and an individual extension owner.  In the process we might also
have to decide who owns, (for example), "Special Pages".  Should we recruit
someone, fold that into the maintainership of "mediawiki as a whole", or is
it not really a separate module.  The former option encourages more
granular maintainer ship, the middle option devolves into the current "big
3 architect" system in the limit case, and the latter option is a technical
finding.

Note that there are also quasi-technical solutions here: if I want to get a
patch reviewed for a particular SpecialPage, for instance, usually I will
do a git log on that piece of the source and assign the last three
committers to the file as reviewers.  One could imagine that something like
that might scale: the last three committers are the defacto owners of a
given component, if there aren't other owners given.  This would work well
with a more hierarchical system.  I might end up as the defacto owner of
the SpecialRedirect page, but changes could also be reviewed by other
owners up the chain: the owner of SpecialPages as a whole (no current
owner), ..., the owner(s) of mediawiki as a whole, the owners of
mediawiki-as-deployed-by-WMF, ..., the big three.

We haven't really thought much about the hierarchy and intermediate owners
here; I guess that's where my proposal differs most from the flat list at
https://www.mediawiki.org/wiki/Developers/Maintainers .
 --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[C. Scott Ananian]

I'm a little puzzled here: this whole discussion is because new owners want
to have the bug actually assigned to them, instead of just commenting, "I'm
working on this" in the bug?

Let's look at the github model -- there's no assignment at all.  I just
file a bug, maybe make some comments on it to say I'm working on it, and
some time later I submit a pull request referencing the bug and saying, "I
fixed it".  That seems to work fine for collaboration, and offers no
roadblocks.

Maybe we should be turning off bugzilla features instead of trying to 'fix'
them.  The whole 'file a bug in bugzilla' process is already far too
complicated with a dozen fields which are either irrelevant or just
confusing to newcomers.  Can we just hide all this cruft (including the
'assigned to' field) for most users?
  --scott


On Thu, Nov 7, 2013 at 11:51 AM, Isarra Yos  wrote:

> On 07/11/13 16:28, Quim Gil wrote:
>
>> The issue is the extra step for newcomers vs the risk of many extra
>> steps for a few etablished contributors if someone decides to abuse the
>> feature, as it happened in the past. And my point is that I personally
>> don't believe that such barrier is diminishing the volume of actual
>> contributions we receive.
>>
>> In order to get somewhere with this discussion, it would be useful to
>> know the current practice of other free software projects, using
>> Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME,
>> KDE, Ubuntu, Debian... etc?
>>
>
> Would that be useful, though? Generally what other free software projects
> do is what works for them, and it won't necessarily work for us. It is also
> most especially not necessarily good practice when it comes to actually
> attracting and keeping new folks, simply due to the nature of what free
> software often entails - somewhere along the line, there is usually a lack
> of resources, and it is newcomers who suffer the most.
>
> As much as projects would like, and for that matter, need, new folks, they
> only have so much time to devote to it and especially when volunteers make
> up a bulk of the community people wind up spending most time on other
> things. Bugzilla lacks certain key features that would make it feasible to
> open up from the start, and my guess would be it has something to do with
> similar - it was simply not a priority, so it never happened.
>
> For a rather extreme example, there was another project, some OS thing,
> that a friend of mine wanted to contribute to awhile back, but he found
> that they had disabled account creation entirely due to lack of resources
> to combat spam, requiring instead that you find them on IRC or some such
> and contact them that way for an account. In no way is this good practice,
> and has very much harmed them as well, and yet it was probably the best
> thing they could do with what they had.
>
> Just please be careful when looking at what other people do, here. Why
> they did something can be far more important than what they actually did.
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Module storage is coming

[Jon Robson]

I'm not sure why shift reloading would make the cache grow since the
same page should load exactly the same modules - if that's not the
case that points at a bug somewhere.

That said since there are a potentially infinite amount of
modules/gadgets, many of which are rarely used that can be loaded in
localStorage it could be a good idea to control this somehow - e.g.
only cache commonly loaded modules . Ori have you thought much about
this approach? I could imagine two approaches:

1) only caching modules loaded by startup module
2)  keeping a counter for each module name to count how many times it
loads and when it hits a certain threshold only then the css/js is
cached. For instance there is not much point in caching a bit of JS
that runs on
3) a mixture of these 2 approaches

I was just reminded also of an old talk I went to [1] which had
awesome ideas for maximising storage that might be worth exploring.
Since JavaScript uses UTF-16 for text encoding the idea was
essentially to convert to UTF-8/ASCII to get up to 50% compression
ratio. There were also ideas about bit shifting base64. Worth
exploring and making this even more of a dangerous experiment?!?! :D

[1] http://lanyrd.com/2012/londonjs-10/srdzy/

On Thu, Nov 7, 2013 at 8:38 AM, Chris McMahon  wrote:
> On Thu, Nov 7, 2013 at 8:05 AM, Jon Robson  wrote:
>
>> From personal experience don't touch cache manifests with a barge pole...
>>
>> Bear in mind the majority of browsers provide at least 5mb of local storage
>> and we are talking about caching a few kB at most of minified
>> JavaScript
>> On 7 Nov 2013 00:35, "Daniel Friesen"  wrote:
>>
>
> What I'm seeing in Chromium/Chrome is that when I invoke VisualEditor one
> time localStorage hits ~3.5MB immediately.
>
> Hit shift-reload a few times in quick succession and it's pretty easy to
> max out localStorage for Chromium at 5.xMB.  Default for Chrome seems to be
> 10MB.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
http://jonrobson.me.uk
@rakugojon

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

Re: [Wikitech-l] Optimizing the deployment train schedule

[C. Scott Ananian]

On Mon, Oct 21, 2013 at 4:36 PM, Jon Robson  wrote:

> Having mobile just joined it the only feedback I can give so far is it
> is confusing knowing what is where but I'm not quite sure how to
> improve that confusion yet other than having a gerrit page which tells
> me what is deployed everywhere so i can check out the state of
> mediawiki.org or en.wiki when debugging issues.
>

It seems to me that having a gerrit (or other) page somewhere which lists
exactly what is currently deployed where (and when the next scheduled
deploy is) is a prerequisite for all of the more aggressive "let's mix up
the set of wikis in early deploy" suggestions.
 --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Optimizing the deployment train schedule

[Jon Robson]

That would indeed be useful C. Scott.
Actually the people that seem to care most about what is currently
deployed where are product owners and designers from my experience who
are not usually technical. It would be good to give them an easy way
to look this up as I spend a lot of time debugging why something is
not live...

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

Re: [Wikitech-l] Module storage is coming

[C. Scott Ananian]

On Thu, Nov 7, 2013 at 12:22 PM, Jon Robson  wrote:

> I'm not sure why shift reloading would make the cache grow since the
> same page should load exactly the same modules - if that's not the
> case that points at a bug somewhere.
>

Seems like a bug, to me.


> That said since there are a potentially infinite amount of
> modules/gadgets, many of which are rarely used that can be loaded in
> localStorage it could be a good idea to control this somehow - e.g.
> only cache commonly loaded modules . Ori have you thought much about
> this approach? I could imagine two approaches:
>
> 1) only caching modules loaded by startup module
> 2)  keeping a counter for each module name to count how many times it
> loads and when it hits a certain threshold only then the css/js is
> cached. For instance there is not much point in caching a bit of JS
> that runs on
> 3) a mixture of these 2 approaches
>

It seems like it would also be useful for gadgets/extensions to be able to
interact with the resource loader, to effectively say, "reserve X bytes for
me".  Maybe this is just having a programmatic way for gadgets/extensions
to throw out the LRU bytes in the resource loader cache if they try to save
something to local storage and fail.  Alternatively: a priority scheme, so
gadgets can automatically get prioritized access to the limited amount of
localStorage.


> I was just reminded also of an old talk I went to [1] which had
> awesome ideas for maximising storage that might be worth exploring.
> Since JavaScript uses UTF-16 for text encoding the idea was
> essentially to convert to UTF-8/ASCII to get up to 50% compression
> ratio. There were also ideas about bit shifting base64. Worth
> exploring and making this even more of a dangerous experiment?!?! :D
>

I've played around with some of these ideas in the past.  I'm not sure it's
worth it, in the end.  The spec doesn't actually say how the localstorage
accounting works in the browser, so even though strings are "nominally"
UTF-16, it's not clear that browsers are using "size in UTF-16 encoding" as
their internal quota metric.  More likely they are using size in whatever
internal representation they have.  As far as the spec is concerned, the
browser can compress the stored data itself to maximize space available to
user scripts... or just increase the quota allowance.  I've had some
conversations about this with the mobile firefox guys.

If you wanted to play around with this, though,
https://github.com/cscott/nell-colors/blob/master/src/lzw.js contains an
implementation of lzw compression optimized for storage in UTF-16 strings.

If you really want to maximize storage, you'd be better off using the
IndexedDB API, which allows you to directly store byte arrays.  Then you
could use all the fancy compression algorithms in
https://github.com/cscott/compressjs to really squeeze things down.  (Or
just use the byte arrays to ensure that the script is stored in UTF8.)

It's a tradeoff, though.  A bandwidth-limited user might tolerate the
slowdown of compression, but if you're trying to use the cache to speed
things up for a high-bandwidth desktop user it's hard to make compression
pay for itself.
 --scott





>
> [1] http://lanyrd.com/2012/londonjs-10/srdzy/
>
> On Thu, Nov 7, 2013 at 8:38 AM, Chris McMahon 
> wrote:
> > On Thu, Nov 7, 2013 at 8:05 AM, Jon Robson  wrote:
> >
> >> From personal experience don't touch cache manifests with a barge
> pole...
> >>
> >> Bear in mind the majority of browsers provide at least 5mb of local
> storage
> >> and we are talking about caching a few kB at most of minified
> >> JavaScript
> >> On 7 Nov 2013 00:35, "Daniel Friesen" 
> wrote:
> >>
> >
> > What I'm seeing in Chromium/Chrome is that when I invoke VisualEditor one
> > time localStorage hits ~3.5MB immediately.
> >
> > Hit shift-reload a few times in quick succession and it's pretty easy to
> > max out localStorage for Chromium at 5.xMB.  Default for Chrome seems to
> be
> > 10MB.
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> http://jonrobson.me.uk
> @rakugojon
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Optimizing the deployment train schedule

[C. Scott Ananian]

Even us technical folks are often ignorant of the deeper ways of ops.  When
I last fixed a long-standing bug in the PHP parser with the potential to
cause regressions in existing wikitext, it was not exactly trivial to keep
track of where the code was currently live (and exactly when it went live)
 -- complicated by the fact that I was convinced that the code *wasn't*
actually in production, despite all evidence to the contrary, because HTML
Tidy was turned on in production and hid the beneficial effects of my
patch.  That's just anecdotal evidence of the fact that making
deployment/version info as obvious as possible can be useful even for
"ordinary bug fixers".
  --scott


On Thu, Nov 7, 2013 at 12:30 PM, Jon Robson  wrote:

> That would indeed be useful C. Scott.
> Actually the people that seem to care most about what is currently
> deployed where are product owners and designers from my experience who
> are not usually technical. It would be good to give them an easy way
> to look this up as I spend a lot of time debugging why something is
> not live...
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] CONFLICT (content): Merge conflict in RELEASE-NOTES-1.23

[C. Scott Ananian]

Could we do an end run around to fix this?  For example add a

Release-Notes: this text shows up in the release notes

field to the commit.  Before release branching, some slightly-fancier
variant of "git log | egrep '^Release-Notes:'" gets run to automatically
populate the release notes with the appropriate information.  Then we don't
have to fiddle with the merge algorithm.
  --scott



On Wed, Nov 6, 2013 at 4:43 AM, Bartosz Dziewoński wrote:

> On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso 
> wrote:
>
>  We could surely add a feature in Zuul that would let us ignore conflicts
>> for some files.  That should be possible by defining a merge driver
>> using the "ours" strategy and then apply that driver in /.gitattributes
>> for the RELEASE-NOTES* files.
>>
>
> You could probably use my driver for this (linked in earlier post, also
> [1]), which does some mostly meaningful checks to decide if the release
> notes are mergeable.
>
>
>
>  A side effect is that the gate-and-submit jobs would work properly but
>> Gerrit would end up refusing to submit the patchset because it cant
>> merge it :-/
>>
>
> Yeah… JGit (which is what gerrit uses instead of git) does also supports
> merge drivers (or so says its documentation), it can't possibly be very
> hard to set one up – someone would just have to reimplement the algorithm
> in Java.
>
> Or maybe we could have another bot to rebase using my driver before
> gate-and-submit runs. But personally I have no idea if/how it could be
> implemented; Antoine?
>
>
> [1] https://github.com/MatmaRex/mediawikireleasenotes-driver
>
> --
> Matma Rex
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Optimizing the deployment train schedule

[Greg Grossmeier]

> On Mon, Oct 21, 2013 at 4:36 PM, Jon Robson  wrote:
> 
> > Having mobile just joined it the only feedback I can give so far is it
> > is confusing knowing what is where but I'm not quite sure how to
> > improve that confusion yet other than having a gerrit page which tells
> > me what is deployed everywhere so i can check out the state of
> > mediawiki.org or en.wiki when debugging issues.
> >
> 
> It seems to me that having a gerrit (or other) page somewhere which lists
> exactly what is currently deployed where (and when the next scheduled
> deploy is) is a prerequisite for all of the more aggressive "let's mix up
> the set of wikis in early deploy" suggestions.

Best we have right now is a combination of:
The wmfXX release notes pages (autogenerated with love by Reedy).
eg: https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf2

The "Included In" dropdown in Gerrit.
eg, go to https://gerrit.wikimedia.org/r/#/c/93980/, click "Included in"
see a list of "Master" and "wmf/1.23wmf3".

Now, you need to correlate 1.23wmf3 and:
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_deployments
(which is updated by hand by mostly Reedy and sometimes me)


Yeah, not elegant at all.

Who wants to devote some time to making a nice purty dashboard for this
info? :)


Greg

>  --scott
> 
> -- 
> (http://cscott.net)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Optimizing the deployment train schedule

[Quim Gil]

On 11/07/2013 10:07 AM, Greg Grossmeier wrote:
> Who wants to devote some time to making a nice purty dashboard for this
> info? :)

It's probably a bit late for this northernHemisphere(Winter), but...

You can trust that someone will take it from here in the next 6 months,
or you can write one paragraph and a related enhancement request in
Bugzilla, and post it at

https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects

Yes, I know you know but, you know...  :)

-- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

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

Re: [Wikitech-l] CONFLICT (content): Merge conflict in RELEASE-NOTES-1.23

[Bartosz Dziewoński]

On Thu, 07 Nov 2013 19:03:33 +0100, C. Scott Ananian  
wrote:


Could we do an end run around to fix this?  For example add a
Release-Notes: this text shows up in the release notes
field to the commit.  Before release branching, some slightly-fancier
variant of "git log | egrep '^Release-Notes:'" gets run to automatically
populate the release notes with the appropriate information.  Then we don't
have to fiddle with the merge algorithm.
  --scott


https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation

Merge drivers aren't nothing exceptionally fancy, and it wouldn't require much 
fiddling (I've already written the code that does the work and been using it 
since, it's perfect). But we need someone with access to appropriate parts of 
the infrastructure to set it up for gerrit/Jenkins, and I don't have it.


--
Matma Rex

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Antoine Musso]

Le 07/11/13 17:55, C. Scott Ananian a écrit :
> Note that there are also quasi-technical solutions here: if I want to get a
> patch reviewed for a particular SpecialPage, for instance, usually I will
> do a git log on that piece of the source and assign the last three
> committers to the file as reviewers.

I do the same thing when asking for review with OpenStack (they are
using Gerrit).  Basically:

# get the Gerrit reviews
git fetch -v gerrit refs/notes/review:refs/notes/review

# Then look at voters:
git log -n20 --notes=review|egrep '(Code-Review|Verified)'


But I am diverging from the main topic ...

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] CONFLICT (content): Merge conflict in RELEASE-NOTES-1.23

[C. Scott Ananian]

On Thu, Nov 7, 2013 at 1:16 PM, Bartosz Dziewoński wrote:

> On Thu, 07 Nov 2013 19:03:33 +0100, C. Scott Ananian <
> canan...@wikimedia.org> wrote:
>
>  Could we do an end run around to fix this?  For example add a
>> Release-Notes: this text shows up in the release notes
>> field to the commit.  Before release branching, some slightly-fancier
>> variant of "git log | egrep '^Release-Notes:'" gets run to automatically
>> populate the release notes with the appropriate information.  Then we
>> don't
>> have to fiddle with the merge algorithm.
>>   --scott
>>
>
> https://www.mediawiki.org/wiki/Requests_for_comment/
> Release_notes_automation


Both those proposals seem good to me.  I'll add that "non-noteworthy
commits" can always be marked in the commit message (an explicit
'Release-Notes: no' field, or [NOREL] in the subject or somewhere in the
body, etc etc).  That should further reduce the amount of manual release
notes editing.


> Merge drivers aren't nothing exceptionally fancy, and it wouldn't require
> much fiddling (I've already written the code that does the work and been
> using it since, it's perfect). But we need someone with access to
> appropriate parts of the infrastructure to set it up for gerrit/Jenkins,
> and I don't have it.


I thought the main problem there was that gerrit/Jenkins would still block
the merge, even with a custom merge driver.  But if that's not the case,
then yes making edited RELEASE-NOTES Just Work is even simpler (maybe not
better?).  But I don't have the necessary access either...
 --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] CONFLICT (content): Merge conflict in RELEASE-NOTES-1.23

[Bartosz Dziewoński]

On Thu, 07 Nov 2013 19:29:06 +0100, C. Scott Ananian  
wrote:


I thought the main problem there was that gerrit/Jenkins would still block
the merge, even with a custom merge driver.  But if that's not the case,
then yes making edited RELEASE-NOTES Just Work is even simpler (maybe not
better?).  But I don't have the necessary access either...


There are two parts to the problem:
1) jenkins voting V-1 because it can't merge the change – would be trivially
   alleviated by installing the merge driver on it, since it uses the standard
   git implementation for everything. Depending how it is setup:
  * If it reuses one git repo, somebody would just have to copy the driver
file and set some config options once.
  * If it creates new repos all the time, the setup would have to be made into
a script – my driver actually comes as such "installer" script [1] which
just needs to be run in the repo directory and then Just Works.

2) gerrit not being able to merge the changes. We can't just install the
   driver, because it uses JGit (a git implementation in Java). We could do
   two things here too:
  * Rewrite my merge plugin in Java to work with JGit, once it's made to
support them. This is apparently ongoing work [2], I'm sure they'd be
happy to receive help.
  * Have jenkins rebase each change as part of the gate-and-submit pipeline
using the merge driver we installed on it per 1). This would also make the
history graph prettier by getting rid of merge commits (the graph
currently looks like [3]…), which I've heard Chad in particular wants very
much.

This really isn't insurmountable, but nobody who is able to do any of these
things seems to care :(

[1] 
https://github.com/MatmaRex/mediawikireleasenotes-driver/blob/master/mediawikireleasenotes-driver-installer.sh
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=418149
[3] http://i.imgur.com/OmFyFbi.png

--
Matma Rex

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

[Wikitech-l] Dashboard for code deployments; where, when, what? (was: Optimizing the deployment train schedule)

[Greg Grossmeier]

> You can trust that someone will take it from here in the next 6 months,
> or you can write one paragraph and a related enhancement request in
> Bugzilla, and post it at
> 
> https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects

Wasn't sure where to put it there, and I wanted it to exist as a project
that anyone (not just mentees) could work on, so I created:
https://www.mediawiki.org/wiki/Wikimedia_Release_%26_QA_Team/Wishlist

Feel free to include wherever :)

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

[Wikitech-l] Possibly affecting our multimedia future: WebRTC codec meeting in a few minutes

[Brion Vibber]

The WebRTC IETF working group will be making a codec selection decision
(VP8 vs H.264) today -- the meeting is open to participation via XMPP chat
(Google Talk appears to work) and there will also be a live audio stream
from the in-person room.

(WebRTC is the peer-to-peer media connection infrastructure for HTML5 which
will in future enable things like Google Hangout video chats using only
open standards. This has obvious potential benefits to us, so we may have
an interest in how this turns out.)


Agenda: http://tools.ietf.org/wg/rtcweb/agenda?item=agenda-88-rtcweb.html

Meeting will start in about 15 minutes (21:00 UTC) and will run about two
hours.

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Marcin Cieslak]

> Let's look at the github model -- there's no assignment at all.  I just
> file a bug, maybe make some comments on it to say I'm working on it, and
> some time later I submit a pull request referencing the bug and saying, "I
> fixed it".  That seems to work fine for collaboration, and offers no
> roadblocks.

GitHub issues are owned by whoever submitted them (and the project
owner). You can't for example convert an issue to a pull request
if you are a third-party. 

But you can always reference an issue in a commit or a comment though.

//Saper


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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Andre Klapper]

On Thu, 2013-11-07 at 08:33 -0800, Chad wrote:
> On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier  wrote:
> 
> > I like the idea of giving everyone who has editbugs the right to give
> >  other people the editbugs permission.  That's certainly worth a try
> > assuming it's possible to configure.
> >
> >
> I want to underscore this again. I think this is a great idea
> and I haven't seen any objections to it yet. Can we go ahead
> with this proposal?

There seems to be sufficient support to grant users who have "editbugs"
rights the permission to hand out (and revert) editbugs rights to/of
other users.

If we did this, users with editbugs rights can go to "Links >
Administration > Users", enter the email address of a user, and hand out
editbugs to other users.

However, the right to hand out editbugs rights to other users cannot be
handed out recursively: If I give user X the right to hand out editbugs
permissions to other users, then user X can only give editbugs to user Y
him/herself, but user Y will NOT automatically be able to hand out
editbugs to user Z.

For the records: Currently 14744 Wikimedia Bugzilla users have editbugs
permissions (so this is something to do via an SQL command instead of me
clicking myself to death in Bugzilla's web interface).

andre

-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

Re: [Wikitech-l] Possibly affecting our multimedia future: WebRTC codec meeting in a few minutes

[Brion Vibber]

I missed most of the meeting relay as I had to run out for some errands,
but little birdies on IRC tell me that the outcome was deadlocked. There
will continue to be video codec drama on the WebRTC working group mailing
lists, and no guarantee of video interoperability between browsers from
different vendors.

And of course  and  tags also still have no mandatory minimum
codec support, so status quo reigns supreme in HTML5 video with
incompatible browser implementations. Awesome!

-- brion


On Thu, Nov 7, 2013 at 12:47 PM, Brion Vibber  wrote:

> The WebRTC IETF working group will be making a codec selection decision
> (VP8 vs H.264) today -- the meeting is open to participation via XMPP chat
> (Google Talk appears to work) and there will also be a live audio stream
> from the in-person room.
>
> (WebRTC is the peer-to-peer media connection infrastructure for HTML5
> which will in future enable things like Google Hangout video chats using
> only open standards. This has obvious potential benefits to us, so we may
> have an interest in how this turns out.)
>
>
> Agenda: http://tools.ietf.org/wg/rtcweb/agenda?item=agenda-88-rtcweb.html
>
> Meeting will start in about 15 minutes (21:00 UTC) and will run about two
> hours.
>
> -- brion
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Module storage is coming

[Daniel Friesen]

We may want to make some considerations for multiple wiki on the same
origin though.

For example a wiki that uses paths for multiple languages:
wiki.example.com/en/Foo
wiki.example.com/fr/Foo
wiki.example.com/de/Foo
...

On a setup like this all the wikis will share the same localStorage
origin and a number of them will fill up the localStorage with cache
entries for each wiki if a user visits them all.
Most of these cache entries will likely be duplicates of the contents of
other wiki.
So we may want to consider a setup where the current localStorage cache
stores hashes and then stores the actual module data inside a different
localStorage key which is shared among wiki.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 2013-11-07 7:05 AM, Jon Robson wrote:
> From personal experience don't touch cache manifests with a barge pole...
>
> Bear in mind the majority of browsers provide at least 5mb of local storage
> and we are talking about caching a few kB at most of minified JavaScript

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

Re: [Wikitech-l] Dashboard for code deployments; where, when, what? (was: Optimizing the deployment train schedule)

[MZMcBride]

Greg Grossmeier wrote:
>
>> You can trust that someone will take it from here in the next 6 months,
>> or you can write one paragraph and a related enhancement request in
>> Bugzilla, and post it at
>> 
>> https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
>
>Wasn't sure where to put it there, and I wanted it to exist as a project
>that anyone (not just mentees) could work on, so I created:
>https://www.mediawiki.org/wiki/Wikimedia_Release_%26_QA_Team/Wishlist

Both this reply and your previous reply give the impression that you have
no interest in directly working on a code deployment dashboard yourself.
Perhaps a stupid question, but why is that?

Sam seems to have the deployments to the wikis under control and the Marks
seem to have the third-party releases under control. This seems like a
good project for you.

MZMcBride



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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Jeremy Baron]

On Nov 7, 2013 6:27 PM, "Andre Klapper"  wrote:
> For the records: Currently 14744 Wikimedia Bugzilla users have editbugs
> permissions (so this is something to do via an SQL command instead of me
> clicking myself to death in Bugzilla's web interface).

I also generally support this. But maybe we can limit to only users that
have done at least one or two actions in the last X months. Or exclude
people that haven't logged in for a year. 14.7k sounds like a lot.

Also, what is the current method for marking bad users and making sure they
don't get promoted? Like CentralAuth's lock.

After the first batch who can then make more people who can grant editbugs?
is this going to be a regular automated thing? manually done each X weeks?

Also, I'm less clear about the remove editbugs form users part. That could
be more restricted than granting.

Max, et al. what do you think?

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[MZMcBride]

C. Scott Ananian wrote:
>Maybe we should be turning off bugzilla features instead of trying to
>'fix' them.  The whole 'file a bug in bugzilla' process is already far too
>complicated with a dozen fields which are either irrelevant or just
>confusing to newcomers.  Can we just hide all this cruft (including the
>'assigned to' field) for most users?

I think we should certainly evaluate and re-evaluate the Bugzilla
workflow. There are surely fields in the current form that could be killed
or made smarter (e.g., only display if necessary). It'd be nice to have a
bug to track doing this evaluation, though I think any audit will find
that the 'assigned to' field in particular is too disruptive to remove.

The general point about trusting new users is what this thread is about.
Isarra's post makes for good reading. :-)

Isarra Yos wrote:
>For a rather extreme example, there was another project, some OS thing,
>that a friend of mine wanted to contribute to awhile back, but he found
>that they had disabled account creation entirely due to lack of
>resources to combat spam, requiring instead that you find them on IRC or
>some such and contact them that way for an account. In no way is this
>good practice, and has very much harmed them as well, and yet it was
>probably the best thing they could do with what they had.

We're doing really well on this front, I think. Users can create a
Gerrit/Labs/Wikitech account easily and without manual intervention.

Jeremy Baron wrote:
>On Nov 7, 2013 6:27 PM, "Andre Klapper"  wrote:
>>For the records: Currently 14744 Wikimedia Bugzilla users have editbugs
>>permissions (so this is something to do via an SQL command instead of me
>>clicking myself to death in Bugzilla's web interface).
>
>I also generally support this. But maybe we can limit to only users that
>have done at least one or two actions in the last X months. Or exclude
>people that haven't logged in for a year. 14.7k sounds like a lot.

Okay.

As to your other questions, I'm confident we'll be able to figure out the
logistical details, if needed.

MZMcBride



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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Chad]

On Thu, Nov 7, 2013 at 6:02 PM, Jeremy Baron  wrote:
>
> Also, what is the current method for marking bad users and making sure they
> don't get promoted? Like CentralAuth's lock.
>
>
Spammers can have their account set to "disabled" by any BZ admin.
They'll get a disabled message when trying to login.

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

[Wikitech-l] Updating the RELEASE-NOTES format for 1.22 and 1.23

[Mark A. Hershberger]

I've already posted to mediawiki-l to try and get input from end users
on these proposed changes [1], but I'd like to see if we can't change
the RELEASE-NOTES format for the time that we're working on 1.23.

The main thing I've done is a bit of reordering and collection:

* New features
* Breaking changes (collected in a single section)
* Configuration changes
* Bug fixes
* API changes
* Language updates
* Misc changes

This is an effort to put the things users to know most about in a new
release at the top of the file.

This could even be done using git comments as others have suggested.

Does this seem like a reasonable approach going forward?

Thanks for any comments,

Mark.

[1] http://article.gmane.org/gmane.org.wikimedia.mediawiki/42443

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

Re: [Wikitech-l] Updating the RELEASE-NOTES format for 1.22 and 1.23

[Arcane 21]

Seems like a reasonable approach to me. The old release notes were a little 
hard to follow, but your suggestion should make them more straightforward from 
now on.

> Date: Thu, 7 Nov 2013 22:21:52 -0500
> From: m...@nichework.com
> To: wikitech-l@lists.wikimedia.org
> Subject: [Wikitech-l] Updating the RELEASE-NOTES format for 1.22 and 1.23
> 
> I've already posted to mediawiki-l to try and get input from end users
> on these proposed changes [1], but I'd like to see if we can't change
> the RELEASE-NOTES format for the time that we're working on 1.23.
> 
> The main thing I've done is a bit of reordering and collection:
> 
> * New features
> * Breaking changes (collected in a single section)
> * Configuration changes
> * Bug fixes
> * API changes
> * Language updates
> * Misc changes
> 
> This is an effort to put the things users to know most about in a new
> release at the top of the file.
> 
> This could even be done using git comments as others have suggested.
> 
> Does this seem like a reasonable approach going forward?
> 
> Thanks for any comments,
> 
> Mark.
> 
> [1] http://article.gmane.org/gmane.org.wikimedia.mediawiki/42443
> 
> ___
> 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] Dashboard for code deployments; where, when, what? (was: Optimizing the deployment train schedule)

[Greg Grossmeier]

> Both this reply and your previous reply give the impression that you have
> no interest in directly working on a code deployment dashboard yourself.
> Perhaps a stupid question, but why is that?

I have interest, just right now not much time. I would love to just do
it but realistically won't get anything significant any time soon.

> Sam seems to have the deployments to the wikis under control and the Marks
> seem to have the third-party releases under control. This seems like a
> good project for you.

Along with everything else, yeah. ;) Thanks for the tip. :)

I'm also looking into reusing something like the Etsy pushbot for
helping with the [[wikitech:Lightning deploys]] when they get busy.

But this was already on my 'task list' (I use taskwarrior):

greg@x200s:~$ task list

ID Proj  Pri DueAge  Description  
23 wmf.relengM   11/13/2013 1d   design what I want from a dashboard


That's referring to a dashboard for a number of things; not just where
the code is when.


Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Erik Moeller]

On Thu, Nov 7, 2013 at 1:15 AM, Faidon Liambotis  wrote:

Faidon,

great questions.

> The "architect" title, besides the job description that you described, is
> also a seniority level within the WMF's engineering department.  Other
> organizations do e.g.  "sr./staff/sr. staff" and/or numeric levels, we do
> "associate / (blank) / sr. / (lead) architect". At least that's my
> understanding of what was presented during the last all-staff and documented
> on officewiki.

On mediawiki.org:  https://www.mediawiki.org/wiki/Wikimedia_Engineering/Careers

> What would happen to this seniority level, if any of the options you
> presented were to be adopted? You seem to hint that there would be a mapping
> with option D ("salary increases") but it's not clear to me how direct of a
> mapping or a prerequisite would that be.

Let me try to respond to this and your other comments in one go. Folks
who don't care about WMF internals should stop reading at this point.
This stuff doesn't matter to everyone, if it doesn't matter to you,
that's OK. :)

There are four main salary band levels we work with in engineering:
entry-level, mid-level, senior level, and director/architect level.
Each of these bands is pretty wide, i.e. tens of thousands of dollars
for an SF-based hire between the lowest and the highest point. There's
a lot of room for progression within a given band, and it's OK for
folks to live outside a given band, which tends to make this somewhat
less urgent in practical terms. That said, one of the fundamental
principles I believe in is that it should be possible to progress to
the highest salary band on either the development or the management
side.

It seems that based on the discussion, nobody's particularly in favor
of a broad community process regarding architecture roles, so some of
the intricacies of progression tied in any way to such a process may
be moot. What might have some degree of traction, based on the
discussion, is to have some blessed delegation coming from the
original triumvirate of architects.

In practice, I could see this tie into the career progression at WMF
in two main ways:

1) We continue to (rarely but sometimes) use the Architect title as
the highest salary band in engineering, and promote people into it
based on a track record of continued architectural leadership, as
proven in a do-o-cracy framework like the one suggested by Brion.

2) We don't award Architect as a job title beyond the original
triumvirate, but we _do_ introduce a Senior Software Engineer II (same
band as the Architect band), and would define some criteria for that,
among which proven architectural leadership could be one. We can
choose to still recognize any continued membership in something like a
core maintainers groups etc. in a person's role, but that's decoupled
from the salary band and can change, consistent with the idea that it
should be OK for an architect to spend time doing other fun &
important things, rather than being locked into one set of
responsibilities forever.

I think the second is more consistent with the tenor of the discussion
here so far, because in the first case, the coupling between job
titles and responsibilities in our community might be too tight to
maintain flexibility and openness. It would also recognize that
technical leadership doesn't _just_ mean taking on broad architectural
responsibilities. So for example development of unique and
mission-critical domain expertise might be another way to progress
into Sr. II.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Quim Gil]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/07/2013 08:55 AM, C. Scott Ananian wrote:
> On Thu, Nov 7, 2013 at 11:44 AM, Quim Gil  wrote:
> 
>> Is your proposal different from
>> https://www.mediawiki.org/wiki/Developers/Maintainers ?
>>
> 
> No, it builds on it.  The current wiki page isn't official, nor complete.
>  I'm suggesting that we embrace it officially, and that we further add

Yes, that would be useful indeed.

Together with this, we could also map the software components developed
upstream that we are using and, hopefully, contributing to. For
instance, Chad is our expert in Gerrit, he follows the development
upstream and he has an idea of what we need and what could we eventually
contribute.

Which are the other key upstream projects, and who are the respective
owners? A solid architecture relies in solid foundations.

- -- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSfI7nAAoJEF0lRQxG2NZBsNkP/2uc+YALsoh694ObEj8nV4o+
jXqm15mxQtCYnYklPWu333op+f6rzE9+9X0HMVgsRCW/xrLl+1gg6vnr0MLHLE6L
1uqC7KISj78U71NSXl0RObE+kI4hVOWKOjQMYB/yuoGDmQRhpYDk0bUleo4HfvdU
z7U5BIhjAxQIXtLsqK6CYMevGMntZgusya7xxtXeL7VlegnlL8oQjH69x2e/NBfe
xSbWLZRre93sNwUfBNnpcvgT1kbQdJSY0mhV3513shAGYaPJNC0PN5UN8RHPgUjv
GWRkxwmA1ZVIgjf8ME7wbj6Wc+0YFc35OnTwe9iyUfUae7XJzYIEiohFWKeTLIhJ
iCbPRd3vP9QrF5YDgS4hH9nxJDWAPhW1Clgb9yJwvJ0CioantjzHfyQySMrqHZcs
hX7sHfS1U5TU0OEQBsEZnplK39rsZhoM853VgjoJ8Dh6B+fVYyWL7TGiroGHMzr5
Y2O6n5Avp8z9gXEHl/BYC8r9X5v+XiJiAWDVLB7Cdd49OYhQqeubkthRmVnGBr/p
rZrvfXkm9lbrthmbPT+zvQFmsk5J4bDq9EKgP0keNpnv4+xAYITWMo/vYCIHpkuN
7S37fdfHEMdVKpR/j7DSVn/t1sqkEz7MOwzxoWGni1BBT8f/8EO7dDOT2c2RRrsG
PL09LgsEQpm1CrRw0kCq
=gjHK
-END PGP SIGNATURE-

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