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,
On Wed, Nov 6, 2013 at 3:18 PM, Quim Gil q...@wikimedia.org 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
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
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
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
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 dan...@nadir-seen-fire.com wrote:
On Nov 7, 2013 12:29 AM, Steven Walling steven.wall...@gmail.com wrote:
On Wed, Nov 6, 2013 at 3:18 PM, Quim Gil q...@wikimedia.org wrote:
We just finished the meeting, and you can find the notes at
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 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
On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier ro...@wikimedia.org 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
On Thu, 07 Nov 2013 17:33:14 +0100, Chad innocentkil...@gmail.com wrote:
On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier ro...@wikimedia.org 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
On Thu, Nov 7, 2013 at 8:05 AM, Jon Robson jdlrob...@gmail.com 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
On Wed, Nov 6, 2013 at 10:13 AM, Brion Vibber bvib...@wikimedia.org 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
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
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
On Thu, Nov 7, 2013 at 11:44 AM, Quim Gil q...@wikimedia.org 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
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
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
On Mon, Oct 21, 2013 at 4:36 PM, Jon Robson jdlrob...@gmail.com 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
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
On Thu, Nov 7, 2013 at 12:22 PM, Jon Robson jdlrob...@gmail.com 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
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)
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
quote name=C. Scott Ananian date=2013-11-07 time=12:27:06 -0500
On Mon, Oct 21, 2013 at 4:36 PM, Jon Robson jdlrob...@gmail.com 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
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
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 |
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
On Thu, Nov 7, 2013 at 1:16 PM, Bartosz Dziewoński matma@gmail.comwrote:
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
On Thu, 07 Nov 2013 19:29:06 +0100, C. Scott Ananian canan...@wikimedia.org
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
quote name=Quim Gil date=2013-11-07 time=10:12:42 -0800
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
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
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
On Thu, 2013-11-07 at 08:33 -0800, Chad wrote:
On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier ro...@wikimedia.org 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
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
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
Greg Grossmeier wrote:
quote name=Quim Gil date=2013-11-07 time=10:12:42 -0800
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
On Nov 7, 2013 6:27 PM, Andre Klapper aklap...@wikimedia.org 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
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
On Thu, Nov 7, 2013 at 6:02 PM, Jeremy Baron jer...@tuxmachine.com 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
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
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
quote name=MZMcBride date=2013-11-07 time=20:11:35 -0400
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.
On Thu, Nov 7, 2013 at 1:15 AM, Faidon Liambotis fai...@wikimedia.org 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
-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 q...@wikimedia.org wrote:
Is your proposal different from
https://www.mediawiki.org/wiki/Developers/Maintainers ?
No, it builds on it. The current wiki
44 matches
Mail list logo
