Re: [Wikitech-l] New Bugzilla users have restricted accounts
On 11/06/2013 04:54 PM, Chad wrote: How about we make editbugs self-granting? That is, if you've got editbugs you can give it to others (like we did with Coder a few years ago). It works pretty well, scales infinitely, and tends to protect itself against abuse. I agree with the others that the status quo is not a huge problem. Occasionally, people ask for editbugs, and they get it. It's still a obstacle; the question is just how significant. Thus, I think this idea is worth trying. If the vandal suddenly reappears, it's pretty easy to figure out who they are or who let them in at that point. Yep. I'm assuming there is an easy to lookup log for this. There's still the possibility that vandals will be really disruptive, and do things like chains of editbugs, sleeper accounts, etc. But if so we can turn it off again, and/or require that people be stricter (on risk of losing their own editbugs), to stop the root of the chain. Some kind of auto-confirmed (e.g. 5+ bug edits and 4 days) would be better (i.e. you have editbugs, and you're autoconfirmed, so you can grant), but I'm not sure how difficult that is to implement Matt Flaschen ___ 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
On 11/08/2013 11:09 PM, Steven Walling wrote: I would be okay just turning off assignment. I don't support turning off assignment. A large number of MediaWiki projects use only Bugzilla (which is also the only open source tracker the WMF uses). Even for stuff WMF engineers work on, there are plenty of bugs only in Bugzilla. Assignment is useful to me for multiple reasons, but the most important are: 1. Marking things I'm definitely going to work on (while trying to avoid cookie-licking). Importantly, I can unmark myself as assigned, signally that it's "back in the pool". 2. (Less commonly) Assigning other people, most commonly on things I think they have the inclination and expertise to fix. Matt Flaschen ___ 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
On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling wrote: > On Fri, Nov 8, 2013 at 2:12 PM, Chad wrote: >> Not all teams have drank the Mingle Kool-Aid yet ;-) > That includes mine. :) Chad: does Platform really depend on bug assignment? Yes. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployment highlights - week of November 11th
I forgot one important note about next Thursday's MediaWiki deploy. It'll include: * MassMessage [6] rollout to all wikis Happy days of no longer using a bot for sending newsletters! [6] https://www.mediawiki.org/wiki/Extension:MassMessage Greg > Hello there, > > Here's what's coming up in the world of Wikimedia project deployments. > > As always, the full known schedule is available on Wikitech: > https://wikitech.wikimedia.org/wiki/Deployments > > Next week: > https://wikitech.wikimedia.org/wiki/Deployments#Week_of_November_11 > > == Throughout the week == > > Ops (Mark B) moving front end cache servers to Varnish[0] (from Squid) > in our Ashburn[1] datacenter. Should be done early in the week pending > issues. > > [0] https://wikitech.wikimedia.org/wiki/Varnish > [1] https://wikitech.wikimedia.org/wiki/Eqiad > > == Monday == > > NOTHING - US Holiday (Veterans Day) > > > == Tuesday == > > * CirrusSearch [2] set as secondary for nl.wikipedia > * MediaWiki 1.23wmf3 [3] to all non-Wikipedia sites (Wiktionary, > Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few > other sites) > > [2] https://www.mediawiki.org/wiki/Extension:CirrusSearch > [3] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf3 > > > == Thursday == > * Swift [5] (object storage) will have a master replaced (pending other > blocking tasks). > * CirrusSearch [2] set as secondary for it.wikipedia and > pl.wiktionary.org > * MediaWiki 1.23wmf3 [3] to all Wikipedias > * MediaWiki 1.23wmf4 [4] to all testwikis > (test/test2/testwikidata/loginwiki/mediawiki) > > > [2] https://www.mediawiki.org/wiki/Extension:CirrusSearch > [4] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf4 > [5] https://wikitech.wikimedia.org/wiki/Swift (Outdated) > > > All the best, > > Greg > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New project on labs for unit tests
Petr I'll try to setup Travis tests to run on every github commit on Monday. :) That seems like the best solution as the repo is on github! Also this way you'll be able to see the status of the tests for all branches and pull requests etc :-) Addshore On 8 Nov 2013 17:22, "Petr Bena" wrote: > to explain how QT unit testing works a bit more, it's basically > another QT project that includes the source code from master branch > and produces a binary file (called tst_testmain) which can be executed > with various parameters and executes the unit tests defined in its > source code, for example: > > petanb@petrbena:~/Public/huggle3-qt-lx/huggle/tests/test$ ./tst_testmain > * Start testing of HuggleTest * > Config: Using QTest library 4.8.6, Qt 4.8.6 > PASS : HuggleTest::initTestCase() > PASS : HuggleTest::testCaseWikiUserCheckIP() > PASS : HuggleTest::cleanupTestCase() > Totals: 3 passed, 0 failed, 0 skipped > * Finished testing of HuggleTest * > > > This thing of course can be ran by some 3rd tool (such as jenkins) > which run it automatically when new commit arrives to repository and > evaluates the results... > > On Fri, Nov 8, 2013 at 5:16 PM, Petr Bena wrote: > > Yes, I made a simple unit test suite for huggle, which uses internal > > QT unit test system, basically what I need to do is > > > > * periodically pull the latest version of source code from master branch > > * build the test suite (if build is failed submit this information) > > * execute test suite (qt unit test system can even produce results as > > XML, or other commonly used formats) > > * evaluate the results and if there are any failures submit this > > information somewhere > > > > the "somewhere" for submitting should be preferable shell script I can > > write, which would send the data directly to our irc channel, so that > > we can be notified immediately if any commit breaks any test. > > > > I don't really know if this is something what Jenkins can be used for, > > but I was told by Coren that running this task on Tools project is not > > a right thing to do. So I am basically looking for another project > > where we could run these unit tests. (It requires g++, make and full > > qt4 dev sdk to be installed on server where unit tests are about to be > > ran) > > > > On Fri, Nov 8, 2013 at 3:40 PM, Antoine Musso > wrote: > >> Le 08/11/13 11:21, Petr Bena a écrit : > >>> would anyone experienced (like hashar) be interested in setup of > >>> jekins on wikimedia labs so that we can get a unit test environment > >>> available to all devs for any projects, written in languages like: > >>> > >>> * C > >>> * C++ > >>> * Python > >>> * PHP > >> > >> If the project is hosted on Wikimedia Gerrit installation, you can > >> surely get jobs added on the existing installation. The jobs > >> configuration are handled using Jenkins Job Builder and trigger by Zuul: > >> > >> integration/jenkins-jobs-builder-config.git > >> integration/zuul-config.git > >> > >> Do you have any use case in mind? > >> > >> -- > >> Antoine "hashar" Musso > >> > >> > >> ___ > >> 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Deployment highlights - week of November 11th
Hello there, Here's what's coming up in the world of Wikimedia project deployments. As always, the full known schedule is available on Wikitech: https://wikitech.wikimedia.org/wiki/Deployments Next week: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_November_11 == Throughout the week == Ops (Mark B) moving front end cache servers to Varnish[0] (from Squid) in our Ashburn[1] datacenter. Should be done early in the week pending issues. [0] https://wikitech.wikimedia.org/wiki/Varnish [1] https://wikitech.wikimedia.org/wiki/Eqiad == Monday == NOTHING - US Holiday (Veterans Day) == Tuesday == * CirrusSearch [2] set as secondary for nl.wikipedia * MediaWiki 1.23wmf3 [3] to all non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) [2] https://www.mediawiki.org/wiki/Extension:CirrusSearch [3] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf3 == Thursday == * Swift [5] (object storage) will have a master replaced (pending other blocking tasks). * CirrusSearch [2] set as secondary for it.wikipedia and pl.wiktionary.org * MediaWiki 1.23wmf3 [3] to all Wikipedias * MediaWiki 1.23wmf4 [4] to all testwikis (test/test2/testwikidata/loginwiki/mediawiki) [2] https://www.mediawiki.org/wiki/Extension:CirrusSearch [4] https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf4 [5] https://wikitech.wikimedia.org/wiki/Swift (Outdated) All the best, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | signature.asc Description: Digital signature ___ 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
On Fri, Nov 8, 2013 at 2:31 PM, Chad wrote: > On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling > wrote: > >> On Fri, Nov 8, 2013 at 2:12 PM, Chad wrote: >> >> > Not all teams have drank the Mingle Kool-Aid yet ;-) >> >> >> That includes mine. :) Chad: does Platform really depend on bug >> assignment? >> Maybe Dan Garry could chime in here as well. >> >> > People may use it. I don't. I basically ignore assignee/status/priority > fields. > > *assignee/severity/priority. I totally do care about status :) -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
On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling wrote: > On Fri, Nov 8, 2013 at 2:12 PM, Chad wrote: > > > Not all teams have drank the Mingle Kool-Aid yet ;-) > > > That includes mine. :) Chad: does Platform really depend on bug assignment? > Maybe Dan Garry could chime in here as well. > > People may use it. I don't. I basically ignore assignee/status/priority fields. -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
On Fri, Nov 8, 2013 at 2:12 PM, Chad wrote: > Not all teams have drank the Mingle Kool-Aid yet ;-) That includes mine. :) Chad: does Platform really depend on bug assignment? Maybe Dan Garry could chime in here as well. ___ 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
On Fri, Nov 8, 2013 at 2:09 PM, Steven Walling wrote: > On Thu, Nov 7, 2013 at 9:06 AM, C. Scott Ananian >wrote: > > > 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 > > > > I would be okay just turning off assignment. > > In theory, a primary use case for assigning bugs is Product Manager A (say, > me) sees a new bug, and assigns it to Engineer B (say, Ori). Other than > self-assignment, this kind of workflow is the most common argument for > needing assignment I think. Since generally, WMF engineering teams use a > secondary task tracking tool (Trello, Mingle, etc.), turning off the > feature would not hurt us. We can also, you know, talk to people if we want > them to tackle a bug. > Not all teams have drank the Mingle Kool-Aid yet ;-) -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
On Thu, Nov 7, 2013 at 9:06 AM, C. Scott Ananian wrote: > 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 > I would be okay just turning off assignment. In theory, a primary use case for assigning bugs is Product Manager A (say, me) sees a new bug, and assigns it to Engineer B (say, Ori). Other than self-assignment, this kind of workflow is the most common argument for needing assignment I think. Since generally, WMF engineering teams use a secondary task tracking tool (Trello, Mingle, etc.), turning off the feature would not hurt us. We can also, you know, talk to people if we want them to tackle a bug. Since we have PATCH TO REVIEW and cross-linking from Gerrit to BZ, it becomes clear who is actually working on resolving an issue. This also focuses more on actually getting working software patches, instead of just fiddling with bugs. ;) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New project on labs for unit tests
On Fri, 8 Nov 2013, at 20:51, Petr Bena wrote: > Hi, > > would anyone experienced (like hashar) be interested in setup of > jekins on wikimedia labs so that we can get a unit test environment > available to all devs for any projects, written in languages like: > > * C > * C++ > * Python > * PHP > > + other frequently used languages And Perl. Gryllida > > I think it would be useful for some (at least me) people :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Memento Extension for MediaWiki: Advice on Further Development
This worked beautifully.
Thanks Daniel Friesen,
--Shawn
From: wikitech-l-boun...@lists.wikimedia.org
[wikitech-l-boun...@lists.wikimedia.org] on behalf of Daniel Friesen
[dan...@nadir-seen-fire.com]
Sent: Saturday, November 02, 2013 7:08 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Memento Extension for MediaWiki: Advice on Further
Development
On 2013-11-02 11:53 AM, Shawn Jones wrote:
> That makes me feel a little bit better about our dependencies.
>
> Since our rewrite, we only use $wgServer (via abstraction) in two places now,
> and they both involve the TimeMap SpecialPage.
>
> We actually have 3 different types of TimeMaps in the Memento Mediawiki
> Extension:
> 1. full (starter) - shows the latest 500 revisions
> 2. pivot descending - shows the last 500 (or less) revisions prior to a given
> timestamp pivot
> 3. pivot ascending - shows the next 500 (or less) revisions after a given
> timestamp pivot
>
> The pivot ascending and pivot descending TimeMaps are what use the $wgServer
> URI.
>
> They take the form of
> http://example.com/index.php/Special:TimeMap/2013072003/1/Article for
> ascending and
> http://example.com/index.php/Special:TimeMap/2013072003/-1/Page for
> descending.
>
> The $wgServer variable is used (as $this->mwbaseurl) to construct the URIs
> like so:
>
> $timeMapPage['uri'] = $this->mwbaseurl . '/'
> . SpecialPage::getTitleFor('TimeMap') . '/'
> . $pivotTimestamp . '/-1/' . $title;
>
> A similar statement exists for a pivot ascending TimeMap elsewhere in the
> code.
>
> I've been trying to find a way to eliminate the use of $wgServer altogether,
> but need to construct these URIs for headers, TimeMap entries, etc.
>
> Is there a better way?
>
$timeMapPage['uri'] = SpecialPage::getTitleFor( 'TimeMap',
$pivotTimestamp . '/-1/' . $title )->get{???}URL();
{???} will be Full, Local, or Canonical depending on where you're
outputting it.
* href="" -> Local
* Somewhere used on other domains -> Full (does output protocol-relative)
* Print and email -> Canonical
* HTTP Headers -> Local + wfExpandUrl( , PROTO_CURRENT ); Unless you
use OutputPage::redirect in which case you can simply use Local as
url expansion is taken care for you.
~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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [outages] Wikipedia down?
Yes, there was downtime. Things should be back up now. -Chad On Fri, Nov 8, 2013 at 11:43 AM, George Herbert wrote: > There was a report of external issues reaching en.wikipedia.org - nginx > timeouts - about 1 hour ago, also reported resolved. > > Forwarding in from outages-l as I haven't seen any internal discussion... > > > -george > > -- Forwarded message -- > From: Marco Davids (SIDN) > Date: Fri, Nov 8, 2013 at 10:29 AM > Subject: [outages] Wikipedia down? > To: "outa...@outages.org" > > > I get an error-page on: > > http://en.wikipedia.org/wiki/Sun_Secure_Global_Desktop > > https://twitter.com/marcodavids/status/398878863071006720 > > -- > Marco > ___ > Outages mailing list > outa...@outages.org > https://puck.nether.net/mailman/listinfo/outages > > > > -- > -george william herbert > george.herb...@gmail.com > ___ > 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
[Wikitech-l] Fwd: [outages] Wikipedia down?
There was a report of external issues reaching en.wikipedia.org - nginx timeouts - about 1 hour ago, also reported resolved. Forwarding in from outages-l as I haven't seen any internal discussion... -george -- Forwarded message -- From: Marco Davids (SIDN) Date: Fri, Nov 8, 2013 at 10:29 AM Subject: [outages] Wikipedia down? To: "outa...@outages.org" I get an error-page on: http://en.wikipedia.org/wiki/Sun_Secure_Global_Desktop https://twitter.com/marcodavids/status/398878863071006720 -- Marco ___ Outages mailing list outa...@outages.org https://puck.nether.net/mailman/listinfo/outages -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architecture Summit: participants confirmed
On 11/08/2013 03:55 AM, Alex Monk wrote: > Hi, I am a volunteer contributor requiring sponsorship, but I don't appear > to have received an email regarding it... Please could you look into this? Sorry, this is only a consequence of an extremely busy week. We hope to send the email with details to sponsored participants... today? Don't worry. You will have hotel and flights. Thank you for your understanding. -- 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] Architectural leadership in Wikimedia's technical community
On Fri, Nov 8, 2013 at 9:00 AM, Bryan Davis wrote: > I think that picking the title "Senior Software Engineer II" may be > underselling the value of this highest tier to the outside world. In > my recent job search I saw a bit of the tech ladder side of the org > chart for several companies. Most of the ladders I saw had a title of > "Principal Engineer" for the top level of non-management engineers. That's totally fair, and I like "Principal" as an alternative. It has strong leadership implications, but leadership can take many forms, and the criteria for a promotion from "Senior" to "Principal" could make that clear. -- 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] Module storage is coming
I've used cache manifests for offline applications. It works reasonably well in that situation. So I wouldn't dismiss it entirely for all purposes. But it's not the right solution here. --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Module storage is coming
On Fri, Nov 8, 2013 at 11:33 AM, Jon Robson wrote: > .. 3) it is a nightmare > http://alistapart.com/article/application-cache-is-a-douchebag is a good > read to anyone who is curious to the why. > I wouldn't go so far to say it is a "nightmare". The article you linked blows things way out of proportion. In reality cache manifests are just one of those "cool new features" that people like to use even if it's not a proper solution for their application. The ApplicationCache behaves in a fairly defined manner, as I explained above. It's just an additional cache on top of normal HTTP caching that permanently caches files based on a manifest. From that article, the only true "gotcha" I would mention is #5, which explains that files not part of the cache manifest will actually not be loaded, even if you're online. That aspect is a little unintuitive, but once you know about it, it's not really a problem. Even more amusing is the second part of the article that attempts to use ApplicationCache for caching Wikipedia, which, like I just said, is exactly *not* what ApplicationCache was meant for. In the end I can understand the reason cache manifests exist: for explicitly offline applications. If your application is not an offline application, then you should not be using cache manifests in the first place, because that's not what it's meant for. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ 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
On Thu, Nov 7, 2013 at 10:38 PM, Erik Moeller wrote: > 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. I personally think this route (separating the role of architectural leadership from the title/pay band of WMF employees) is the most reasonable way forward. I also think it fits well with the concepts of role flexibility that Erik has been expressing. Being given the title of Architect was a nice recognition of my value to the organization at my last employer, but it was actually a bit of a hindrance during my recent job search. Many recruiters were initially reluctant to put my resume forth for positions that required hands-on software development because they equated the Architect title with strategic planning more than top-tier development. I don't think that Tim, Brion or Mark would have any trouble demonstrating their abilities to anyone they decided they would rather work for, but it's something to be cognizant of. I think that picking the title "Senior Software Engineer II" may be underselling the value of this highest tier to the outside world. In my recent job search I saw a bit of the tech ladder side of the org chart for several companies. Most of the ladders I saw had a title of "Principal Engineer" for the top level of non-management engineers. Bryan -- Bryan Davis Wikimedia Foundation [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Module storage is coming
.. 3) it is a nightmare http://alistapart.com/article/application-cache-is-a-douchebag is a good read to anyone who is curious to the why. On 8 Nov 2013 07:06, "Tyler Romeo" wrote: > On Fri, Nov 8, 2013 at 9:45 AM, Antoine Musso wrote: > > > So what is a cache manifest? :D > > > tl;dr - Cache manifests are made for offline web apps, and Wikipedia is not > an offline web app. > > Cache manifests are a new HTML5 feature that is specifically made for > single page (or, at the very least, few-paged) offline web apps. You add a > special attribute to the tag of all pages in your application. The > value of the attribute is a URL to a manifest file (it has its own mime > type and everything). In this file it specifies what pages in your > application should be explicitly cached. > > The difference between cache manifests and normal browser caching is that > the browser will never update the cache unless the manifest changes. In > other words, if it has an offline copy, it will always serve it unless the > manifest file changes. > > This is useful in cases where you have a web app that is entirely > front-end, i.e., once you download the HTML files you don't need to do > anything else (think something along the lines of a single player game). > That way the files will be permanently cached and the user can view the > website even if the site itself is offline. Most apps in the Chrome Web > Store will use this technique to have their web app stored. > > There are multiple reasons it is not used here: > > 1) Wikipedia is not a single-paged app, it is many, many pages, and every > page of the app usually links to the manifest. It would be strange to have > any Wikipedia article a user visits permanently stored in the user's > browser. (Before somebody says "well just don't put articles in the > manifest", any page that has the manifest attribute is implicitly cached, > regardless of if it's in the manifest.) > > 2) It doesn't solve the actual problem. The problem here is the issue of > combining all JS files into one. We combine all the files using RL in order > to reduce round-trip time for first-time visitors, but at the same time it > increases what has to be downloaded for previous visitors when updates are > made. Cache manifests do not get around the round-trip time issue, so it > doesn't allow us to split up JS files. And with the JS files still > combined, cache manifests don't have a way to partially update modules. So > in the end it is completely useless. > > See the following links for more information: > https://en.wikipedia.org/wiki/The_cache_manifest_in_HTML5 > http://www.html5rocks.com/en/tutorials/appcache/beginner/ > > *-- * > *Tyler Romeo* > Stevens Institute of Technology, Class of 2016 > Major in Computer Science > ___ > 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] Architectural leadership in Wikimedia's technical community
On Fri, Nov 8, 2013 at 12:38 AM, Erik Moeller wrote: > What might have some degree of traction, based on the > discussion, is to have some blessed delegation coming from the > original triumvirate of architects. +1 I'd personally like to see this kept flexible, so that it's relatively easy to both assign and to hand off projects. Gerrit is littered with abandoned bits and pieces. It should be easy to 'assign' a new owner/"architect" to a component when maintainership seems to be flagging, and owners should be encouraged to hand off ownership when they've moved on. Having to go through a formal process would be a drag. Perhaps every module owner should be required to write a quarterly report, and the next level up in the hierarchy has to write the report for any unowned modules. That would encourage people both to delegate and to hand-off when possible. ;) [mostly joking, we shouldn't be inventing busywork, but I do feel that ownership/"architect" status should ideally come with real responsibilities.] 2) We don't award Architect as a job title beyond the original > triumvirate, but we _do_ introduce a Senior Software Engineer II (same > [...] > I think the second is more consistent with the tenor of the discussion > +1 I'm not a big fan of the actual wording of the "Senior Software Engineer II" title, but I'm sure HR could come up with some comparable titles among our peers. (Maybe "Principal Software Engineer", or something with "Fellow" in it. Other organizations apparently use "Staff Software Engineer" but I'm not a fan of that. [1]) But those are details... --scott [1] see "Fellow" in https://en.wikipedia.org/wiki/Corporate_title ; also see http://programmers.stackexchange.com/questions/117179/what-is-the-job-title-hierarchy-amongst-software-engineersfor some alternatives used elsewhere -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New project on labs for unit tests
to explain how QT unit testing works a bit more, it's basically another QT project that includes the source code from master branch and produces a binary file (called tst_testmain) which can be executed with various parameters and executes the unit tests defined in its source code, for example: petanb@petrbena:~/Public/huggle3-qt-lx/huggle/tests/test$ ./tst_testmain * Start testing of HuggleTest * Config: Using QTest library 4.8.6, Qt 4.8.6 PASS : HuggleTest::initTestCase() PASS : HuggleTest::testCaseWikiUserCheckIP() PASS : HuggleTest::cleanupTestCase() Totals: 3 passed, 0 failed, 0 skipped * Finished testing of HuggleTest * This thing of course can be ran by some 3rd tool (such as jenkins) which run it automatically when new commit arrives to repository and evaluates the results... On Fri, Nov 8, 2013 at 5:16 PM, Petr Bena wrote: > Yes, I made a simple unit test suite for huggle, which uses internal > QT unit test system, basically what I need to do is > > * periodically pull the latest version of source code from master branch > * build the test suite (if build is failed submit this information) > * execute test suite (qt unit test system can even produce results as > XML, or other commonly used formats) > * evaluate the results and if there are any failures submit this > information somewhere > > the "somewhere" for submitting should be preferable shell script I can > write, which would send the data directly to our irc channel, so that > we can be notified immediately if any commit breaks any test. > > I don't really know if this is something what Jenkins can be used for, > but I was told by Coren that running this task on Tools project is not > a right thing to do. So I am basically looking for another project > where we could run these unit tests. (It requires g++, make and full > qt4 dev sdk to be installed on server where unit tests are about to be > ran) > > On Fri, Nov 8, 2013 at 3:40 PM, Antoine Musso wrote: >> Le 08/11/13 11:21, Petr Bena a écrit : >>> would anyone experienced (like hashar) be interested in setup of >>> jekins on wikimedia labs so that we can get a unit test environment >>> available to all devs for any projects, written in languages like: >>> >>> * C >>> * C++ >>> * Python >>> * PHP >> >> If the project is hosted on Wikimedia Gerrit installation, you can >> surely get jobs added on the existing installation. The jobs >> configuration are handled using Jenkins Job Builder and trigger by Zuul: >> >> integration/jenkins-jobs-builder-config.git >> integration/zuul-config.git >> >> Do you have any use case in mind? >> >> -- >> Antoine "hashar" Musso >> >> >> ___ >> 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] New project on labs for unit tests
Yes, I made a simple unit test suite for huggle, which uses internal QT unit test system, basically what I need to do is * periodically pull the latest version of source code from master branch * build the test suite (if build is failed submit this information) * execute test suite (qt unit test system can even produce results as XML, or other commonly used formats) * evaluate the results and if there are any failures submit this information somewhere the "somewhere" for submitting should be preferable shell script I can write, which would send the data directly to our irc channel, so that we can be notified immediately if any commit breaks any test. I don't really know if this is something what Jenkins can be used for, but I was told by Coren that running this task on Tools project is not a right thing to do. So I am basically looking for another project where we could run these unit tests. (It requires g++, make and full qt4 dev sdk to be installed on server where unit tests are about to be ran) On Fri, Nov 8, 2013 at 3:40 PM, Antoine Musso wrote: > Le 08/11/13 11:21, Petr Bena a écrit : >> would anyone experienced (like hashar) be interested in setup of >> jekins on wikimedia labs so that we can get a unit test environment >> available to all devs for any projects, written in languages like: >> >> * C >> * C++ >> * Python >> * PHP > > If the project is hosted on Wikimedia Gerrit installation, you can > surely get jobs added on the existing installation. The jobs > configuration are handled using Jenkins Job Builder and trigger by Zuul: > > integration/jenkins-jobs-builder-config.git > integration/zuul-config.git > > Do you have any use case in mind? > > -- > Antoine "hashar" Musso > > > ___ > 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] New Bugzilla users have restricted accounts
Again, as far as I'm concerned, we're solving a non-problem. Yes, in theory it would be nice if everyone easily got all permissions to everything. But bugzilla is not set up with the antivandal features needed to make that work. Instead, we should aim to make it possible for newcomers to easily get the permissions *that they need*. I'm not convinced that the ability to assign bugs themselves is an ability *that is needed* by most committers. They only think they need it because (1) we make the field visible, along with a bunch of other unused and unnecessary stuff, and (2) we have bugzilla set up to automatically "assign" bugs to default owners, even if (as is usually the case) the default owners do not plan to work on those bugs. If newly entered bugs were put in an unassigned state, and the assignment field was hidden for untrusted users when the bugs were unassigned, I think we wouldn't have a problem here. We'd just handle assignment manually using comments in the bug, just as we go with github, etc. If a user starts working on such a long list of bugs that they need bugzilla's (broken, sigh, but it's what we've got) bug list management functions, they can ask to be officially assigned to a bug and/or ask for 'editbugs' permission. This is a huge subset of committers, and so can be handled manually. The principle is that *new contributors shouldn't face roadblocks*. No one has convinced me that the inability to assign bugs to themselves is actually a *roadblock* for new contributors. It's just a *perceived roadblock*, caused by bugzilla's broken design. --scott On Fri, Nov 8, 2013 at 10:30 AM, Luis Villa wrote: > On Fri, Nov 8, 2013 at 6:52 AM, Andre Klapper >wrote: > > > On Thu, 2013-11-07 at 08:28 -0800, Quim Gil wrote: > > > 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? > > > > It has been a while, but to my recollection, the answer is "no". > > Luis > > -- > Luis Villa > Deputy General Counsel > Wikimedia Foundation > 415.839.6885 ext. 6810 > > NOTICE: *This message may be confidential or legally privileged. If you > have received it by accident, please delete it and let us know about the > mistake. As an attorney for the Wikimedia Foundation, for legal/ethical > reasons I cannot give legal advice to, or serve as a lawyer for, community > members, volunteers, or staff members in their personal capacity.* > ___ > 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
On Fri, Nov 8, 2013 at 6:52 AM, Andre Klapper wrote: > On Thu, 2013-11-07 at 08:28 -0800, Quim Gil wrote: > > 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? > It has been a while, but to my recollection, the answer is "no". Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 NOTICE: *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.* ___ 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
On Thu, 2013-11-07 at 08:28 -0800, Quim Gil wrote: > 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? In case any projects which use Bugzilla allow this: I just learned it's a bad idea [1]. The assignee of a bug report who is not member of the "editbugs" group defacto has "editbugs" permissions for that specific bug report. So you could mass-assign bug reports to you in order to bypass your missing editbugs permissions. andre [1] https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/6GCB7ufa7nc -- 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] New project on labs for unit tests
Le 08/11/13 11:21, Petr Bena a écrit : > would anyone experienced (like hashar) be interested in setup of > jekins on wikimedia labs so that we can get a unit test environment > available to all devs for any projects, written in languages like: > > * C > * C++ > * Python > * PHP If the project is hosted on Wikimedia Gerrit installation, you can surely get jobs added on the existing installation. The jobs configuration are handled using Jenkins Job Builder and trigger by Zuul: integration/jenkins-jobs-builder-config.git integration/zuul-config.git Do you have any use case in mind? -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New project on labs for unit tests
Le 08/11/13 11:24, Petr Bena a écrit : > I noticed there is "integration" project, but what its status is, I don't know That is a play ground area. Merely intended to test out new features for later inclusion in production. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Module storage is coming
On Fri, Nov 8, 2013 at 9:45 AM, Antoine Musso wrote: > So what is a cache manifest? :D tl;dr - Cache manifests are made for offline web apps, and Wikipedia is not an offline web app. Cache manifests are a new HTML5 feature that is specifically made for single page (or, at the very least, few-paged) offline web apps. You add a special attribute to the tag of all pages in your application. The value of the attribute is a URL to a manifest file (it has its own mime type and everything). In this file it specifies what pages in your application should be explicitly cached. The difference between cache manifests and normal browser caching is that the browser will never update the cache unless the manifest changes. In other words, if it has an offline copy, it will always serve it unless the manifest file changes. This is useful in cases where you have a web app that is entirely front-end, i.e., once you download the HTML files you don't need to do anything else (think something along the lines of a single player game). That way the files will be permanently cached and the user can view the website even if the site itself is offline. Most apps in the Chrome Web Store will use this technique to have their web app stored. There are multiple reasons it is not used here: 1) Wikipedia is not a single-paged app, it is many, many pages, and every page of the app usually links to the manifest. It would be strange to have any Wikipedia article a user visits permanently stored in the user's browser. (Before somebody says "well just don't put articles in the manifest", any page that has the manifest attribute is implicitly cached, regardless of if it's in the manifest.) 2) It doesn't solve the actual problem. The problem here is the issue of combining all JS files into one. We combine all the files using RL in order to reduce round-trip time for first-time visitors, but at the same time it increases what has to be downloaded for previous visitors when updates are made. Cache manifests do not get around the round-trip time issue, so it doesn't allow us to split up JS files. And with the JS files still combined, cache manifests don't have a way to partially update modules. So in the end it is completely useless. See the following links for more information: https://en.wikipedia.org/wiki/The_cache_manifest_in_HTML5 http://www.html5rocks.com/en/tutorials/appcache/beginner/ *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Module storage is coming
Le 08/11/13 10:33, Daniel Friesen a écrit : > I'm not interested in writing an entire explanation for you on how cache > manifests work and their faults when you could simply do a web search > for one of the many existing tutorials. If you could explain to the newbie there like me what a cache manifest here, that would help the discussion. Not everyone has the time to attempt to figure out every technical matters, much less figuring it wrong. So what is a cache manifest? :D -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New project on labs for unit tests
TBH I have no idea which sw for this is best, whatever that is working I am fine with... I thought people are using jenkins for MW, so there are likely more people who have experience witht hat On Fri, Nov 8, 2013 at 1:14 PM, Jeroen De Dauw wrote: > Hey, > > What about using TravisCI or any of the many alternatives? I'm not sure > what the benefit would be of setting up and maintaining something like that > yourself. > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > ___ > 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] New project on labs for unit tests
Hey, What about using TravisCI or any of the many alternatives? I'm not sure what the benefit would be of setting up and maintaining something like that yourself. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architecture Summit: participants confirmed
Hi, I am a volunteer contributor requiring sponsorship, but I don't appear to have received an email regarding it... Please could you look into this? Thanks Alex Monk On Thu, Oct 31, 2013 at 6:39 PM, Quim Gil wrote: > Hi, > > https://www.mediawiki.org/wiki/Architecture_Summit_2014#Participants has > been updated in order to reflect the current list of participants confirmed. > > We are in touch with a few contributors from areas currently > underrepresented, and it is possible that some people are still added to > the list. > > Volunteer contributors requiring sponsorship will be contacted via email. > The Wikimedia Foundation will cover their flights and accommodation. Please > email me if you don't hear from us this week. > > Wikimedia Foundation employees not based in San Francisco must contact > their managers for travel arrangements. > > The first MediaWiki Architecture Summit 2014 is looking great at least in > terms of participation. Next: content. Now it's time to focus in the > discussions prior to the event, and the schedule. > > -- > 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New project on labs for unit tests
I noticed there is "integration" project, but what its status is, I don't know On Fri, Nov 8, 2013 at 11:21 AM, Petr Bena wrote: > Hi, > > would anyone experienced (like hashar) be interested in setup of > jekins on wikimedia labs so that we can get a unit test environment > available to all devs for any projects, written in languages like: > > * C > * C++ > * Python > * PHP > > + other frequently used languages > > I think it would be useful for some (at least me) people :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New project on labs for unit tests
Hi, would anyone experienced (like hashar) be interested in setup of jekins on wikimedia labs so that we can get a unit test environment available to all devs for any projects, written in languages like: * C * C++ * Python * PHP + other frequently used languages I think it would be useful for some (at least me) people :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Module storage is coming
I'm not interested in writing an entire explanation for you on how cache manifests work and their faults when you could simply do a web search for one of the many existing tutorials. The issues with using cache manifests to try and do this should be perfectly understandable once someone understands how cache manifests work. They are unusable for this technique. And Ori has already explained the advantage of being able to have modules cached separately. You're basically suggesting we try to make orange juice out of apples instead of oranges. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] On 2013-11-08 12:46 AM, John Erling Blad wrote: > That is a statement, not an explanation. > Please provide a valid explanation why you want to do this. > John > > On Thu, Nov 7, 2013 at 9:35 AM, 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Module storage is coming
That is a statement, not an explanation. Please provide a valid explanation why you want to do this. John On Thu, Nov 7, 2013 at 9:35 AM, 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] Module storage is coming
That is a statement, not an explanation. John On Thu, Nov 7, 2013 at 4:05 PM, 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: > >> 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 ___ 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
Le 07/11/13 18:27, C. Scott Ananian a écrit : > 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. Whenever someone comes with a script, I will be happy to integrate it so it is continuously generated whenever a change is merged in wmf branches. The resulting output can be hosted at https://integration.wikimedia.org/dashboard/ -- Antoine "hashar" Musso ___ 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
Le 08/11/13 04:21, Mark A. Hershberger a écrit : > 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 I would put the 'breaking changes' at the top. The 'new features' tending to be very long. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
