Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
A few random points:
We should get some basic structure conventions in place before stuff goes wild.
I like the idea of installing a Skin as an extension, but placing it in the
core skins directory
feels wrong because it currently does auto-discovery to some degree, and of
course it means
wgExtensionAssetsPath can't be used as skins as it is outside that directory
view.
The way the skins in mediawiki/extensions/skins.git do it is by simply being
installed as a completely valid extension.
Another problem I found in the current setup is that its a bit
counter-intuitive how to manage the directory structure for developers. I mean,
most of us probably have this:
- mediawiki
- /core (clone mediawiki/core.git)
- /extensions (directory with clones of individual extensions or clone of
mediawiki/extensions.git tracking repo)
* Set $wgExtensionAssetsPath accordingly
* Use require_once( "$IP/../extensions/Foo/Foo.php"); (whether or not via a tmp
variable)
instead of require_once( "$IP/extensions/Foo/Foo.php");
But then, where to clone a skins repository (or mediawiki/skins.git tracking
repo)?
Wherever it is, it needs to be scalable to more complex installations. A
directory "skins" next to "extensions" next to "core" is not feasible as the
paths would be incorrect (it wouldn't be in wgExtensionAssetsPath, nor in
wgStylePath).
I think it'd be a lot easier if skins were installed as extensions, not as a
(currently, unhandleable) hybrid.
Maybe as proper extensions in mediawiki/extensions/SkinName.git (and drop
mediawiki/skins/*.git).
That would be the easier, though it is also nice to keep extensions and skins
separate enough in that anything that adds preferences, special pages etc. is
in a separate optional repository.
Or perhaps agree that skins should be installed from mediawiki/skins/*.git
repositories, but clones inside mediawiki/extensions/skins/*. That would mean
in module definitions and require's, we just add an extra /skins/.
In that case we should get rid of mediawiki/extensions/skins.git to avoid
clashes.
-- Krinkle
On Sep 26, 2012, at 1:44 AM, Daniel Friesen wrote:
> Skin pages on MW.org (and repos in Gerrit) are now ready.
>
> MediaWiki.org is now ready for modern skins (ones NOT using old QuickTemplate
> and skins/Foo.php patterns) to have pages about them just like extensions do.
>
> Relevant links:
> https://www.mediawiki.org/wiki/Category:All_skins
> https://www.mediawiki.org/wiki/Template:Skin
>
> Some examples that currently exist:
> https://www.mediawiki.org/wiki/Skin:Erudite
> https://www.mediawiki.org/wiki/Skin:Vector
>
> Gerrit can also handle your skin repos. Ask for a mediawiki/skins/{skinname}
> repo.
> So your skins can now have proper review and be updated with the various
> improvements that get made to MediaWiki's skinning system.
>
> When you do introduce a skin here please do follow the file layout patterns I
> used in my tutorials:
> http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/
> http://blog.redwerks.org/2012/02/28/mediawiki-subskin-tutorial/
> I don't want to see any non-core skins using the outdated skins/TheSkin.php
> pattern in the new skins area.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.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] New extension: Diff
2012/9/26 Tim Starling : > On 26/09/12 03:54, Tyler Romeo wrote: >> This looks pretty interesting. Is there a reason we don't just put this in >> the core? > > It has about 50 lines of useful code wrapped in 1600 lines of > abstraction. I don't think it is the sort of style we want in the core. I am sorry, but I find this comment a bit harsh, and just wanted to deliver some data on that. Maybe it was meant as a hyperbole, in which case I apologize for not treating it as such. The extension has, altogether 2846 total lines of code in 24 files, of which 332 lines are blank, 1328 lines are comments, and 1186 are physical lines of code. Of the latter 1186, 641 are tests. I find that commendable. (That leaves us with 1663 total lines of code, which are probably the 1600 from the original comment) Another 148 physical lines go to initializing the extension and internationalization. Remain 402 physical lines of code. Now, one might discuss the suitability of using interfaces in PHP, but we have that in core: IDBAccessObject, ICacheHelper, IDeviceDetector, and a few others. Not many, but they exist. Anyway, the two interface classes account for only 18 physical lines of code anyway. The only 18 lines a user of the extension needs to care about. One might discuss the suitability of using a class hierarchy to represent different DiffOps. But then again, that is the same class design as in the DairikiDiff engine, included in core as well. There sure are other design choices that can be discussed. But the picture painted above was exaggerated, and I merely wanted to add some data to it. Cheers, Denny P.S.: terminology: "total lines of code" - lines in all code files, "physical lines of code" every line that has at least one non-comment or non-whitespace character. All numbers according to cloc. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
On 26.09.2012 02:49, Aaron Schulz wrote: > Perhaps some code could be restructured > in some cases so that the calls at least match, meaning the splitting of > transactions would at least be more deliberate rather than accidental. I think this is the most important bit here: it should be obvious to the programmer what is going on, and it should be easy to debug when stuff gets committed and why. The behavior of the respective functions should be documented in detail for all the possible situations. My impression is that I'm not the only developer who had the wrong mental model of what begin/commit does, or how it is intended to use. Fixing that is the most important thing. Coming up with ways to actually allow for unbroken nested transactions would be good I think, but that comes second. For the "being obvious" bit, better documentation is the first step. Another possibility would be to provide additional functions (even if they just act as aliases) that allow the programmer to make explicit the desired behavior. The "debug" bit is mostly about when debug messages and warnings should be issued. I see three factors that could influence that: * the DBO_TRX flag * whether write queries have been executed on the connection (since the last commit). * whether wgDebugTransactions is enabled. What do you think, which of these factors should be considered, and how? -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GLAMwiki Toolset Project : Request for Comments - Technical Architecture
On 09/25/2012 12:17 PM, dan entous wrote: I thought the lab instance was only an incubation environment and that the final goal was to put gwtoolset on the WMF prod. servers. Isn't it? the final goal, as far as i understand it, is to have it run as its own application in its own environment, similar to the way some applications are running on the current toolserver. i was told that instead of using the toolserver we should use a wikimedia labs instance. would love to hear if this is not the intended outcome. Hi Dan Sad news :( Having as goal to integrate (at the end) the gwt extension in WMF prod. env. would: * help to involve the rest of the community of developers - at least for the code review process. * improve the global quality of code of the tool by applying WMF high dev/op standards. * remove the work (for the gwt team) of maintaining the environment running (for example avoid scalability issues...) * offer a better visibility to the tool. * simply the understanding for the end-user by using a commons.wikimedia.org builtin solution (instead of a third part tool) Regarding the size and the purpose of the project, we should IMO try to include that goal in the list of outcomes of the gwt project. Emmanuel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
Hey, > Is there a reason we don't just put this in the core? One of the reasons is that from my experience the MediaWiki core dev community is not very open to such things. I think Tim is illustrating the point pretty well, by implying what I did is total nonsense. Having tried to get this into core would have lead to more insults getting thrown at my head. Of course this is nonsense, as I'm sure some core developer will point out in a reply. Another reason is that although this is a rather generic diff utility, the number of extensions that could make use of this seems rather limited. And I don't think we want to just put any generic component into core without good reason. > It has about 50 lines of useful code wrapped in 1600 lines of > abstraction. I don't think it is the sort of style we want in the core. Unsurprisingly I'm going to Agree with Denny that this is rather harsh. This kind of attitude is not very welcoming to other developers, especially if you make such comments where they are not applicable. And yes, I'm going to maintain it's not applicable. Being the genius that you are, I challenge you to put your money where your mount is to write a 50 line extension that offers the same functionality as this extension. One might discuss the suitability of using a class hierarchy to > represent different DiffOps. But then again, that is the same class > design as in the DairikiDiff engine, included in core as well. > Although you find small things to nitpick over, I'm confident the overall design is sound. The Diff and DiffOps are following the composite pattern, which seems very much like the right choice to me. I would not mind being proven wrong or having other constructive discussion though. "This is crap" is not constructive. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
On 26.09.2012 02:08, Tim Starling wrote: > I think that to avoid confusion, begin() and commit() should continue > to issue the queries they are named for. True. So we'd need start() and finish() or some such. > Your scheme does not appear to provide a method for hooks to release > highly contended locks that they may acquire. Lock contention is > usually the most important reason for calling commit(). Holding a > contended lock for an excessive amount of time has often brought the > site down. Imagine if someone wrapped a hook that writes to site_stats > with begin/end. The code would work just fine in testing, and then > instantly bring the site down when it was deployed. I see your point. But if we have the choice between lock contention and silent data loss, which is better? While I agree that inconsistencies in secondary data like link tables is acceptable, I think we do need a way to protect critical transactions to prevent data loss. Hm... if we use flush() for immediate commits, and start() and finish() for blocks that disable immediate commits (i.e. critical transactions), then a "silenced" flush() inside an start() and finish() block should issue a warning. That would make tests fail. Would you be OK with that? So, my current proposal is a more expressive high-level api for transaction control consisting of start/finish/flush (and perhaps abort) on top of the low level interface consisting of begin/commit/rollback. Documentation needs to be very clear on how they behave and how they relate to each other. For the short term, I suggest to suppress warnings about nested transactions under some conditions, see my previous response to aaron. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Can we kill DBO_TRX? It seems evil!
On Wednesday, September 26, 2012, Daniel Kinzler wrote: > > I see your point. But if we have the choice between lock contention and > silent > data loss, which is better? This isn't really a choice - by default, when a statement in mysql hits a lock timeout, it is rolled back but the transaction it's in is not. That can also lead to data loss via partial writes in real world cases if not properly accounted for by the application. Avoiding holding locks longer than needed really should be paramount. Developers need to adapt to cases where transaction semantics alone can't guarantee consistancy across multiple write statements. We're planning on sharding some tables this year and there will be cases where writes will have to go to multiple database servers, likely without the benefit of two phase commit. That doesn't mean that we should give up on consistancy or that we shouldn't try to do better, but not in exchange for more lock contention. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
On 26.09.2012 12:06, Asher Feldman wrote: > On Wednesday, September 26, 2012, Daniel Kinzler wrote: >> >> I see your point. But if we have the choice between lock contention and >> silent >> data loss, which is better? > > > This isn't really a choice - by default, when a statement in mysql hits a > lock timeout, it is rolled back but the transaction it's in is not. Uh. That sounds evil and breaks the A in ACID, no? Why isn't the entire transaction rolled back in such a case? > That > can also lead to data loss via partial writes in real world cases if not > properly accounted for by the application. How could we detect such a case? > That doesn't mean that we should give up on consistancy or > that we shouldn't try to do better, but not in exchange for more lock > contention. Well, improving consistency and avoiding data loss is going to be hard without the use of locks... how do you propose to do that? -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
I have submitted two changes for review that hopefully remedy the current problems: * I1e746322 implements better documentation, more consistent behavior, and easier tracking of implicit commits in Database::begin() * I6ecb8faa restores the "flushing" commits that I removed a while ago under the assumption that a commit without a begin would be a no-op. I hope this addresses any pressing issues. I still think that we need a way to protect critical sections. But an RFC seems to be in order for that. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Announcement: Mark Holmquist joins Wikimedia as Features Engineer
Hello everyone, It’s with great pleasure that I’m announcing that Mark Holmquist has joined the Wikimedia Foundation as a Feature Engineer. Mark is a free software advocate and software engineer. Before joining us, he was getting his B.S. in Computer Science at the University of Redlands. You may have remembered him from back when he was a student doing the WMF org chart before he graduated in June of this year, or as a contractor working on UploadWizard and assorted bug zapping. :-) He has contributed to many free software projects in the past, including Minetest, Etherpad, and OpenHatch. Recently he has worked on the EtherEditor extension for MediaWiki[0]. BTW, Erik will be wanting to suck your 20% time into finishing out the outstanding bugs. ;-) On the side, he enjoys playing Bridge[1] and the occasional jaunt for Parkour[2]. He lives in the Mission in foggy San Francisco. He also really enjoy reading and discussing court cases, either oral arguments or decisions. He's subscribed to the Cornell Supreme Court bulletin [3], so bug him about the cases that are in the news. :-) His first official day was on September 17th, but I flaked out because of the all-staff and then decided to procrastinate some more on this announcement since you already know him from all his participation on IRC and wikitech-l. Until December, he will be working with Gabriel Wicke on the Parsoid, which is the rewrite of the Wikitext parser to work with the VisualEditor proejct (I assume James and Trevor have completed the necessary hazing on the VE Team and he has gotten his t-shirt). But more generally, he'll be on the Features team with Editor Engagement and assorted front-end technical debt here at the WMF. Please join me in welcoming Mark Holmquist to the Wikimedia Foundation. :-) Take care, Terry [0] http://www.mediawiki.org/wiki/Extension:EtherEditor [1] http://en.wikipedia.org/wiki/Contract_bridge [2] https://en.wikipedia.org/wiki/Parkour [3] http://www.law.cornell.edu/supct/cert/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Mark Holmquist joins Wikimedia as Features Engineer
Welcome Mark! - Akshay On Wed, Sep 26, 2012 at 10:27 PM, Terry Chay wrote: > Hello everyone, > > It’s with great pleasure that I’m announcing that Mark Holmquist has > joined the Wikimedia Foundation as a Feature Engineer. > > Mark is a free software advocate and software engineer. Before joining > us, he was getting his B.S. in Computer Science at the University of > Redlands. You may have remembered him from back when he was a student doing > the WMF org chart before he graduated in June of this year, or as a > contractor working on UploadWizard and assorted bug zapping. :-) > > He has contributed to many free software projects in the past, > including Minetest, Etherpad, and OpenHatch. Recently he has worked on the > EtherEditor extension for MediaWiki[0]. BTW, Erik will be wanting to suck > your 20% time into finishing out the outstanding bugs. ;-) > > On the side, he enjoys playing Bridge[1] and the occasional jaunt for > Parkour[2]. He lives in the Mission in foggy San Francisco. He also really > enjoy reading and discussing court cases, either oral arguments or > decisions. He's subscribed to the Cornell Supreme Court bulletin [3], so > bug him about the cases that are in the news. :-) > > His first official day was on September 17th, but I flaked out because > of the all-staff and then decided to procrastinate some more on this > announcement since you already know him from all his participation on IRC > and wikitech-l. Until December, he will be working with Gabriel Wicke on > the Parsoid, which is the rewrite of the Wikitext parser to work with the > VisualEditor proejct (I assume James and Trevor have completed the > necessary hazing on the VE Team and he has gotten his t-shirt). But more > generally, he'll be on the Features team with Editor Engagement and > assorted front-end technical debt here at the WMF. > > Please join me in welcoming Mark Holmquist to the Wikimedia > Foundation. :-) > > Take care, > > Terry > > [0] http://www.mediawiki.org/wiki/Extension:EtherEditor > [1] http://en.wikipedia.org/wiki/Contract_bridge > [2] https://en.wikipedia.org/wiki/Parkour > [3] http://www.law.cornell.edu/supct/cert/ > > > ___ > 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] Announcement: Mark Holmquist joins Wikimedia as Features Engineer
On 12-09-26 10:23 AM, Akshay Agarwal wrote: Welcome Mark! Thanks, Akshay! And thanks to Terry for the intro (I thanked him on the staff list, not here yet), and to wikitech-l for endlessly entertaining conversations :) -- Mark Holmquist Software Engineer, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Announcement: Mark Holmquist joins Wikimedia as Features Engineer
One of us, one of us! :) Congrats, Mark! -- Ori Livneh o...@wikimedia.org On Wednesday, September 26, 2012 at 9:57 AM, Terry Chay wrote: > Hello everyone, > > It’s with great pleasure that I’m announcing that Mark Holmquist has joined > the Wikimedia Foundation as a Feature Engineer. > > Mark is a free software advocate and software engineer. Before joining us, he > was getting his B.S. in Computer Science at the University of Redlands. You > may have remembered him from back when he was a student doing the WMF org > chart before he graduated in June of this year, or as a contractor working on > UploadWizard and assorted bug zapping. :-) > > He has contributed to many free software projects in the past, including > Minetest, Etherpad, and OpenHatch. Recently he has worked on the EtherEditor > extension for MediaWiki[0]. BTW, Erik will be wanting to suck your 20% time > into finishing out the outstanding bugs. ;-) > > On the side, he enjoys playing Bridge[1] and the occasional jaunt for > Parkour[2]. He lives in the Mission in foggy San Francisco. He also really > enjoy reading and discussing court cases, either oral arguments or decisions. > He's subscribed to the Cornell Supreme Court bulletin [3], so bug him about > the cases that are in the news. :-) > > His first official day was on September 17th, but I flaked out because of the > all-staff and then decided to procrastinate some more on this announcement > since you already know him from all his participation on IRC and wikitech-l. > Until December, he will be working with Gabriel Wicke on the Parsoid, which > is the rewrite of the Wikitext parser to work with the VisualEditor proejct > (I assume James and Trevor have completed the necessary hazing on the VE Team > and he has gotten his t-shirt). But more generally, he'll be on the Features > team with Editor Engagement and assorted front-end technical debt here at the > WMF. > > Please join me in welcoming Mark Holmquist to the Wikimedia Foundation. :-) > > Take care, > > Terry > > [0] http://www.mediawiki.org/wiki/Extension:EtherEditor > [1] http://en.wikipedia.org/wiki/Contract_bridge > [2] https://en.wikipedia.org/wiki/Parkour > [3] http://www.law.cornell.edu/supct/cert/ > > > ___ > Wmfall mailing list > wmf...@lists.wikimedia.org (mailto:wmf...@lists.wikimedia.org) > https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
On Sep 25, 2012, at 7:54 PM, Tyler Romeo wrote: > Is there a reason we don't just put this in the core? > Many points have been made already in a short amount of time, which emphasizes how touchy this subject can be. Anyway, a different view that I haven't heard as much is the following. Being in core is not a stamp of approval. This picture never existed and if it did, it needs to go away. We're going towards a flexible modular system, which means components have dependencies and build on each other - as opposed to just "being there". So unless other existing core functionality would need it, it doesn't make sense to include it. Instead, extensions should prove themselves. If an extension provides functionality that other extensions need, those other extensions will simply add "Make sure X and Y is installed first" to their instructions and use it that way. This gives a few advantages: * Fair competition. Extensions can decide that they want to use, make it also easy for developers to fork a utility and improve it (like extensions do). * Flexibility. Once it is in core, we have to support it, which is especially awkward if it isn't in use, because that means we have an untracked dependency on something we don't even use, and can't be easily replaced either because some extension might use it, somehow. It goes at the cost of not having a standard, but I'm not sure a blanket "standard now, must use this" is what we want here, at least not until it has proven itself by being used over a long period of time by other extensions. I mean, things don't have to be in core to be usable. Let it be an extension, let it grow. Extensions can perfectly depend on other extensions, there is no need to have it be in core, make your own decisions. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
On 26 September 2012 10:08, Krinkle wrote: > Another problem I found in the current setup is that its a bit > counter-intuitive how to manage the directory structure for developers. I > mean, most of us probably have this: > > - mediawiki > - /core (clone mediawiki/core.git) > - /extensions (directory with clones of individual extensions or clone of > mediawiki/extensions.git tracking repo) In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
It would be nice if we could convert some additional themes... On Wed, Sep 26, 2012 at 11:01 AM, Niklas Laxström wrote: > On 26 September 2012 10:08, Krinkle wrote: > > Another problem I found in the current setup is that its a bit > counter-intuitive how to manage the directory structure for developers. I > mean, most of us probably have this: > > > > - mediawiki > > - /core (clone mediawiki/core.git) > > - /extensions (directory with clones of individual extensions or clone > of mediawiki/extensions.git tracking repo) > > In SVN time extensions were a subdir of mediawiki core and I doubt > that everyone has suddenly decided to change it. At least I haven't. > -Niklas > > -- > Niklas Laxström > > ___ > 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] [Wmfall] Announcement: Mark Holmquist joins Wikimedia as Features Engineer
On 26 September 2012 09:57, Terry Chay wrote: > It’s with great pleasure that I’m announcing that Mark Holmquist has joined > the Wikimedia Foundation as a Feature Engineer. [Snip] > Until December, he will be working with Gabriel Wicke on the Parsoid, which > is the rewrite of the Wikitext parser to work with the VisualEditor proejct > (I assume James and Trevor have completed the necessary hazing on the VE > Team and he has gotten his t-shirt). Check. :-) Welcome aboard, Mark! James. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester | +1 415-839-6885 x6844 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Announcement: Mark Holmquist joins Wikimedia as Features Engineer
Welcome Mark! I've never been that great at bridge but I'll definitely need to engage you in a couple legal discussions. We have a couple legal nuts in the office (not even counting our amazing legal team, who is also nuts!), we may have to start having more organized debates over drinks/food/bridge etc :) James On Wed, Sep 26, 2012 at 9:57 AM, Terry Chay wrote: > Hello everyone, > > It’s with great pleasure that I’m announcing that Mark Holmquist has > joined the Wikimedia Foundation as a Feature Engineer. > > Mark is a free software advocate and software engineer. Before joining > us, he was getting his B.S. in Computer Science at the University of > Redlands. You may have remembered him from back when he was a student doing > the WMF org chart before he graduated in June of this year, or as a > contractor working on UploadWizard and assorted bug zapping. :-) > > He has contributed to many free software projects in the past, > including Minetest, Etherpad, and OpenHatch. Recently he has worked on the > EtherEditor extension for MediaWiki[0]. BTW, Erik will be wanting to suck > your 20% time into finishing out the outstanding bugs. ;-) > > On the side, he enjoys playing Bridge[1] and the occasional jaunt for > Parkour[2]. He lives in the Mission in foggy San Francisco. He also really > enjoy reading and discussing court cases, either oral arguments or > decisions. He's subscribed to the Cornell Supreme Court bulletin [3], so > bug him about the cases that are in the news. :-) > > His first official day was on September 17th, but I flaked out because > of the all-staff and then decided to procrastinate some more on this > announcement since you already know him from all his participation on IRC > and wikitech-l. Until December, he will be working with Gabriel Wicke on > the Parsoid, which is the rewrite of the Wikitext parser to work with the > VisualEditor proejct (I assume James and Trevor have completed the > necessary hazing on the VE Team and he has gotten his t-shirt). But more > generally, he'll be on the Features team with Editor Engagement and > assorted front-end technical debt here at the WMF. > > Please join me in welcoming Mark Holmquist to the Wikimedia > Foundation. :-) > > Take care, > > Terry > > [0] http://www.mediawiki.org/wiki/Extension:EtherEditor > [1] http://en.wikipedia.org/wiki/Contract_bridge > [2] https://en.wikipedia.org/wiki/Parkour > [3] http://www.law.cornell.edu/supct/cert/ > > > ___ > Wmfall mailing list > wmf...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wmfall > -- James Alexander Manager, Merchandise Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New extension: Diff
> > So unless other existing core functionality would need it, it doesn't make > sense > to include it. > This makes sense. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Sep 26, 2012 at 1:54 PM, Krinkle wrote: > So unless other existing core functionality would need it, it doesn't make > sense > to include it. > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.20 release candidate
Krinkle gmail.com> writes: > > On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger everybody.org> wrote: > > > On 09/22/2012 02:50 PM, Krinkle wrote: > >> On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger everybody.org> wrote: > >>> That commit is not included. I can merge it in or make a second RC with > >>> 1.20wmf12. > >>> > >>> What do you think is the better way to go? > >> > >> I'd say re-branch from master. > > > > My thinking was to branch from a point that was known -- something whose > > issues we knew. I think this worked pretty well. > > > > For instance, the issue Niklas raised was because I used a WMF branch. > > > > I'm now thinking that I'll just stick with the 1.20wmf12 and just apply > > the patch he pointed to. This is in the vein of sticking to known issues. > > > > What do you think? > > > > Mark. > > I think master is more stable then whatever wmf branch. I know because of commits > recently merged and whatnot. > > If there are problems we'll find them in the release candidate period. > And by that time we'll have had a new wmf branch as well to see how the > latest code > performs on wmf. > > Also, this bugzilla query should be empty before release as well (either by fixing bugs, > or reviewing/merging pending commits that claim to fix stuff, or deferring > the bug to > a later release etc.). People assign and block things usually for a reason: > > https://bugzilla.wikimedia.org/buglist.cgi? query_format=advanced&target_milestone=1.20.0%20release&product=MediaWiki&resolu tion=--- > Those reasons for using master can be used in the counter argument. The counter argument has the fact that we've been using said branch in production for upto 2 weeks - we know it works (mostly). Yes, master will have had numerous bugfixes brought into it, but there are also likely "new features" and other bugs introduced. I think using a branch (though, not specifically the WMF branches "as is", due to WMF specific modifications. They want reverting out. Same goes for we don't want any of the extension update to master commits) is the best idea. Branching a REL1_20 branch from say the point that 1.20wmf12 branched, and then also backporting any relevant fixes from master makes sense. Pretty much how we did it for SVN, hopefully without the months and months of merging hell. If we create a REL1_20 release branch now, we should then go through the usual process of bumping $wgVersion, creating RELEASE-NOTES-1.21 and new WMF branches can go back to wmf1 etc as a prefix. Sam ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.20 release candidate
On Wed, Sep 26, 2012 at 3:24 PM, Sam Reed wrote: > Krinkle gmail.com> writes: > >> >> On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger everybody.org> > wrote: >> >> > On 09/22/2012 02:50 PM, Krinkle wrote: >> >> On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger everybody.org> > wrote: >> >>> That commit is not included. I can merge it in or make a second RC with >> >>> 1.20wmf12. >> >>> >> >>> What do you think is the better way to go? >> >> >> >> I'd say re-branch from master. >> > >> > My thinking was to branch from a point that was known -- something whose >> > issues we knew. I think this worked pretty well. >> > >> > For instance, the issue Niklas raised was because I used a WMF branch. >> > >> > I'm now thinking that I'll just stick with the 1.20wmf12 and just apply >> > the patch he pointed to. This is in the vein of sticking to known issues. >> > >> > What do you think? >> > >> > Mark. >> >> I think master is more stable then whatever wmf branch. I know because of > commits >> recently merged and whatnot. >> >> If there are problems we'll find them in the release candidate period. >> And by that time we'll have had a new wmf branch as well to see how the >> latest > code >> performs on wmf. >> >> Also, this bugzilla query should be empty before release as well (either by > fixing bugs, >> or reviewing/merging pending commits that claim to fix stuff, or deferring >> the > bug to >> a later release etc.). People assign and block things usually for a reason: >> >> https://bugzilla.wikimedia.org/buglist.cgi? > query_format=advanced&target_milestone=1.20.0%20release&product=MediaWiki&resolu > tion=--- >> > > Those reasons for using master can be used in the counter argument. The > counter > argument has the fact that we've been using said branch in production for > upto 2 > weeks - we know it works (mostly). > > Yes, master will have had numerous bugfixes brought into it, but there are > also > likely "new features" and other bugs introduced. > > I think using a branch (though, not specifically the WMF branches "as is", due > to WMF specific modifications. They want reverting out. Same goes for we don't > want any of the extension update to master commits) is the best idea. > Branching > a REL1_20 branch from say the point that 1.20wmf12 branched, and then also > backporting any relevant fixes from master makes sense. Pretty much how we did > it for SVN, hopefully without the months and months of merging hell. > > If we create a REL1_20 release branch now, we should then go through the usual > process of bumping $wgVersion, creating RELEASE-NOTES-1.21 and new WMF > branches > can go back to wmf1 etc as a prefix. > I agree with Sam on all counts here (and actually suggested this as well). Since we're getting ready to land ContentHandler, it would be nice to have this branched before that happens. That way 1.20 can remain stable and be near a release ContentHandler will just be the first big thing to land in 1.21 :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
On 26/09/12 19:13, Daniel Kinzler wrote: > I see your point. But if we have the choice between lock contention and silent > data loss, which is better? It's better if you don't have to make that choice. So don't call any hooks while a critical transaction is open. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
On Sep 26, 2012, at 8:01 PM, Niklas Laxström wrote: > On 26 September 2012 10:08, Krinkle wrote: >> Another problem I found in the current setup is that its a bit >> counter-intuitive how to manage the directory structure for developers. I >> mean, most of us probably have this: >> >> - mediawiki >> - /core (clone mediawiki/core.git) >> - /extensions (directory with clones of individual extensions or clone of >> mediawiki/extensions.git tracking repo) > > In SVN time extensions were a subdir of mediawiki core and I doubt > that everyone has suddenly decided to change it. At least I haven't. > -Niklas No, not at all. They never were and never will. In svn we have: [mediawiki] - trunk/ - - phase3/ - - extensions/ Extensions has always been besides never inside core. Of course in unversioned installations (e.g. tarballs) we put extensions in the extensions subdirectory. And even in versioned installations, one can * git clone individual extensions in the extensions directory * git clone extensions next to core and place symlinks for invidual extensions in the extensions directory But if someone simply clones the mediawiki/extensions.git tracking repository, then it is kind of annoying to have to put symlinks in place. I have my local dev environment set up like this: $wgScriptPath = '/mediawiki/core'; $wgExtensionAssetsPath = '/mediawiki/extensions'; $extDir = dirname( $IP ) . '/extensions'; require_once( "$extDir/Vector/Vector.php" ); Anyway, -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
On 27/09/12 01:16, Tim Starling wrote: > On 26/09/12 19:13, Daniel Kinzler wrote: >> I see your point. But if we have the choice between lock contention and >> silent >> data loss, which is better? > > It's better if you don't have to make that choice. So don't call any > hooks while a critical transaction is open. > > -- Tim Starling Can the "critical transactions where world will end if holded a little more" be listed? Not being able to touch things out of fear that it might explode in production (while unable to test it before) is bad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
On 27.09.2012, 3:26 Krinkle wrote: > On Sep 26, 2012, at 8:01 PM, Niklas Laxström > wrote: >> On 26 September 2012 10:08, Krinkle wrote: >>> Another problem I found in the current setup is that its a bit >>> counter-intuitive how to manage the directory structure for developers. I >>> mean, most of us probably have this: >>> >>> - mediawiki >>> - /core (clone mediawiki/core.git) >>> - /extensions (directory with clones of individual extensions or clone of >>> mediawiki/extensions.git tracking repo) >> >> In SVN time extensions were a subdir of mediawiki core and I doubt >> that everyone has suddenly decided to change it. At least I haven't. >> -Niklas > No, not at all. They never were and never will. > In svn we have: > [mediawiki] > - trunk/ > - - phase3/ > - - extensions/ > Extensions has always been besides never inside core. > Of course in unversioned installations (e.g. tarballs) we put extensions in > the extensions subdirectory. And even in versioned installations, one can > * git clone individual extensions in the extensions directory > * git clone extensions next to core and place symlinks for invidual > extensions in the extensions directory > But if someone simply clones the mediawiki/extensions.git tracking > repository, then it is kind of annoying to have to put symlinks in > place. I have my local dev environment set up like this: > $wgScriptPath = '/mediawiki/core'; > $wgExtensionAssetsPath = '/mediawiki/extensions'; > $extDir = dirname( $IP ) . '/extensions'; > require_once( "$extDir/Vector/Vector.php" ); This approach has a problem: Let's take a look at random extension's (AbuseFilter was in the beginning of directory listing) maintenance script: require_once ( getenv( 'MW_INSTALL_PATH' ) !== false ? getenv( 'MW_INSTALL_PATH' ) . "/maintenance/commandLine.inc" : dirname( __FILE__ ) . '/../../maintenance/commandLine.inc' ); If MW_INSTALL_PATH is not set (and nobody sets it), this layout will break all the maintenance scripts. And there are more way extensions rely on themselves being present in $IP/extensions -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
On Wed, Sep 26, 2012 at 4:07 AM, Daniel Kinzler wrote: > On 26.09.2012 12:06, Asher Feldman wrote: > > On Wednesday, September 26, 2012, Daniel Kinzler wrote: > >> > >> I see your point. But if we have the choice between lock contention and > >> silent > >> data loss, which is better? > > > > > > This isn't really a choice - by default, when a statement in mysql hits a > > lock timeout, it is rolled back but the transaction it's in is not. > > Uh. That sounds evil and breaks the A in ACID, no? Why isn't the entire > transaction rolled back in such a case? > There's a distinction (possibly misguided) between cases where a statement can be retried with an expectation of success, and cases that aren't which trigger an implicit rollback. Deadlocks are considered the latter by mysql, they result in a transaction rollback. Oracle behaves the same way as mysql with regards to lock timeouts - it's up to developers to either retry the timed-out statement, or rollback. The results can definitely be evil if not handled correctly, but it's debatable if it's a violation of atomicity. If lock timeout throws an exception that closes the connection to mysql, at least that will result in a rollback. If the connection is pooled and reused, it can likely result in a commit. Mysql does offer a "rollback_on_timeout" option that changes the default behavior. We can enable it at wmf, but since that may not be an option for many installs, it's better to work around it. > That > > can also lead to data loss via partial writes in real world cases if not > > properly accounted for by the application. > > How could we detect such a case? > I can't think of a way that's actually good. Better to account for the behavior. > That doesn't mean that we should give up on consistancy or > > that we shouldn't try to do better, but not in exchange for more lock > > contention. > > Well, improving consistency and avoiding data loss is going to be hard > without > the use of locks... how do you propose to do that? > We could try to identify cases where consistency is extremely important, vs. where it isn't. In the cases where a very important lock holding transaction will be entered, can we defer calling hooks or doing anything unrelated until that transaction is closed at its intended endpoint? If so, perhaps everything else can be subject to current behavior, where unrelated code can call commit. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
On Wed, Sep 26, 2012 at 7:26 PM, Krinkle wrote: > On Sep 26, 2012, at 8:01 PM, Niklas Laxström > wrote: > >> On 26 September 2012 10:08, Krinkle wrote: >>> Another problem I found in the current setup is that its a bit >>> counter-intuitive how to manage the directory structure for developers. I >>> mean, most of us probably have this: >>> >>> - mediawiki >>> - /core (clone mediawiki/core.git) >>> - /extensions (directory with clones of individual extensions or clone of >>> mediawiki/extensions.git tracking repo) >> >> In SVN time extensions were a subdir of mediawiki core and I doubt >> that everyone has suddenly decided to change it. At least I haven't. >> -Niklas > > No, not at all. They never were and never will. > > In svn we have: > > [mediawiki] > - trunk/ > - - phase3/ > - - extensions/ > > Extensions has always been besides never inside core. > Actually, they were back in the day, but were quickly moved out. Early wmf repo history is fun ;-) Fun fact for the day: we rewrote history to remove wikihiero and a couple of other things (should've just deleted them all, grr :\) that were making the core git repo way larger than it needed to be (wikihiero used to have huge uncompressed images). Compare [0] and [1] -Chad [0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/extensions/?view=log&log_pagestart=50 [1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=history;f=extensions;hb=HEAD ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we kill DBO_TRX? It seems evil!
- Original Message - > From: "Asher Feldman" > If lock timeout throws an exception that closes the connection to mysql, at > least that will result in a rollback. If the connection is pooled and > reused, it can likely result in a commit. I would assert that if that's true, than connection pooling is unacceptably Broken As Designed. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin pages on MW.org, and Skin repos in Gerrit
On Sep 27, 2012, at 1:36 AM, Max Semenik wrote: > On 27.09.2012, 3:26 Krinkle wrote: > >> On Sep 26, 2012, at 8:01 PM, Niklas Laxström >> wrote: > >>> On 26 September 2012 10:08, Krinkle wrote: Another problem I found in the current setup is that its a bit counter-intuitive how to manage the directory structure for developers. I mean, most of us probably have this: - mediawiki - /core (clone mediawiki/core.git) - /extensions (directory with clones of individual extensions or clone of mediawiki/extensions.git tracking repo) >>> >>> In SVN time extensions were a subdir of mediawiki core and I doubt >>> that everyone has suddenly decided to change it. At least I haven't. >>> -Niklas > >> No, not at all. They never were and never will. > >> In svn we have: > >> [mediawiki] >> - trunk/ >> - - phase3/ >> - - extensions/ > >> Extensions has always been besides never inside core. > >> Of course in unversioned installations (e.g. tarballs) we put extensions in >> the extensions subdirectory. And even in versioned installations, one can > >> * git clone individual extensions in the extensions directory >> * git clone extensions next to core and place symlinks for invidual >> extensions in the extensions directory > >> But if someone simply clones the mediawiki/extensions.git tracking >> repository, then it is kind of annoying to have to put symlinks in >> place. I have my local dev environment set up like this: > >> $wgScriptPath = '/mediawiki/core'; >> $wgExtensionAssetsPath = '/mediawiki/extensions'; >> $extDir = dirname( $IP ) . '/extensions'; > >> require_once( "$extDir/Vector/Vector.php" ); > > This approach has a problem: > > Let's take a look at random extension's (AbuseFilter was in the > beginning of directory listing) maintenance script: > > require_once ( getenv( 'MW_INSTALL_PATH' ) !== false >? getenv( 'MW_INSTALL_PATH' ) . "/maintenance/commandLine.inc" >: dirname( __FILE__ ) . '/../../maintenance/commandLine.inc' ); > > If MW_INSTALL_PATH is not set (and nobody sets it), this layout will > break all the maintenance scripts. And there are more way extensions > rely on themselves being present in $IP/extensions > That's a known problem, nothing new. And that goes for both extensions and skins alike. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
