Re: [Wikitech-l] Adding extensions under packagist's mediawiki vendor
Le 22/07/2015 16:13, Federico Leva (Nemo) a écrit : Gerrit is too unpredictable for users: https://phabricator.wikimedia.org/T86476#1462980 . It's probably easier and more functional to create some mediawiki-users vendor on packagist and let any MediaWiki sysadmin (not developer) join to add the packages they need for whatever reason. Nemo About https://gerrit.wikimedia.org/r/#/c/225663/ which states: Revert Convert to globals and add composer support The RfC for adding composer support for extensions was declined. We should not be adding composer support to more extensions. Which removes: https://gerrit.wikimedia.org/r/#/c/190027/14/composer.json,unified And honestly I am confused. From my understanding we wanted to come in a position where we use composer to download the packages and resolve the dependencies then the extension loader, potentially having the extension loader as a composer plugin. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Measuring performance
The reading team are currently focusing energy on speeding up the site for all our users (https://phabricator.wikimedia.org/T98986 is the tracking bug where this work can be followed) Off the back of https://phabricator.wikimedia.org/T105361 I had a quick chat with Ori to document how the performance team is currently identifying problems with MediaWiki's code. I'm sharing here, so anyone who is interested in helping us improve the time our users can load our content can analyse our data, raise tasks, and submit patches. I'm hoping this will be useful for anyone who wants to get involved in an effort to make our site faster for our users (this is not desktop specific). If you have anything useful to add please do, after some discussion or nods I'd love to share some best practices on mediawiki.org Tool 1) Use http://webpagetest.org (no credentials necessary) * Use https://en.wikipedia.org/wiki/Facebook as an example wiki page * Choose a region of the world and browser * Select first view only since this is what we are currently interested in (repeat view is when they load again - and it should be quicker as it is from cache). * Capture video can be turned off - I personally find the screenshots more useful To shout out some of the advanced settings, the more interesting/useful features include: *Chrome capture dev tools timeline * Setting speed 3G or 2G * Script can be used to conditionally turn on things which are not yet available to everyone e.g. VisualEditor You can do a lot of this in your Chrome browser locally, but different browsers may have different behaviours and are in a fixed location so this does not get captured in this tool. The visual screenshots also make it easier to see where things get blocked. With the timeline from advanced tools you can match up white screens with blocking scripts/styles Tool 2) Add http://performance.wikimedia.org to your browser bookmarks. Navigation timing section is probably the most interesting right now. It points to https://grafana.wikimedia.org (no credentials needed) which is powered by http://graphite.wikimedia.org (Access graphite with your wikitech credentials). This data is sourced from our users, so is a good representation of how we are doing. If a graph is missing you can create a new one from data in graphite by clicking add row or editing an existing graph. Clicking edit on https://grafana.wikimedia.org/#/dashboard/db/navigation-timing?panelId=12fullscreenedit you'll be able to understand where the data comes from on graphite e.g. metrics/frontend/navtiming/totalPageLoadTime Note for graphs median data is less sensitive to edge cases so best to use this as a more realistic indicator. Folders in graphite, are populated by scripts that live in: https://github.com/wikimedia/operations-puppet/tree/production/modules/webperf/files To create a graph, simply go to an existing workboard, save it under a different name (this clones it) - don't worry you can't mess up and delete existing workboards. Tool 3) Speedcurve requires you to setup an account but it gives you an opiniated view about things you care about and is nicely presented so could be a good source of inspiration for your own grafana dashboard. To oversimplify what it does: each day it will access a page, store result, allow you to see historic data. Note the performance team has plans to setup infrastructure to automate this. Tool 4) is one we are not using - http://sitespeed.io. We might want to use it for performance regressions test. In the grand scheme of things it would be great to get to a place where Jenkins complains if you cause a regression in firstPaint time but we are a long way from that but let's work in that direction :-) Let's live up to the Hawaiian word after which we are named! Apologies if this is oversimplified, please take this as an opportunity to share how you/your team/your company test page performance. I see this mailing list as a good place to share these sort of things! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I love Parsoid but it doesn't want me
Le 23/07/2015 08:15, Ricordisamoa a écrit : Are there any stable APIs for an application to get a parse tree in machine-readable format, manipulate it and send the result back without touching HTML? I'm sorry if this question doesn't make any sense. You might want to explain what you are trying to do and which wall you have hit when attempting to use Parsoid :-) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
Le 22/07/2015 19:20, Ricordisamoa a écrit : * CR fragmentation * CI fragmentation * more reliance on proprietary software This are all valid point and Brian Gerstle did a lot of work on trying to reuse Gerrit/CI because he really wanted an opensource based solution hosted on Wikimedia infrastructure. It turns out that when doing IOS development you need the proprietary XCode that only runs on Apple computer with Mac OS X. That causes a few challenges: * where to host the Mac machines? * how do we deploy and manage their configuration * who is responsible for them * what about security issues? XCode has a few challenges that makes it hard to automatize and is surely going to cost a lot of our precious engineering work to achieve (if at all possible). On the other hand, there are some providers of XCode that are integrated with Github/Travis and grant us everything we need out of the box for free/cheap price. I am very grateful they evaluated and attempted to reuse the existing WMF infra. In the end Brian/mobile team choice is a pragmatic decision and they pick the system that fulfil their needs at minimal cost. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
Hi Brian, The arguments for/against GitHub etc. were discussed at length across all of our engineering staff community, exactly 3 years ago, which reached consensus: https://www.mediawiki.org/wiki/Git/Gerrit_evaluation#GitHub In my opinion, this is not something that should be addressed on a per-team basis (and especially not by making the decision first internally in the team and then announcing it to the wider audience as a done deal). Individual and team-wide preferences should be considered as input to the wider discussion but ultimately people should yield to the collective decision. A per-team decision for critical tooling like the one you just announced would be inappropriate in a corporate setting, and is even more so in a community-facing organization. All this applies to both our Git tooling as well as CI, for which is worth noting that there are people in the foundation working on it full time. It's not very different than our issue tracking tooling either, for which we already know the huge pains that we've suffered in the past by having it fragmented across multiple different tools that each individual team picked. We can always revisit past decisions and reopen past discussions (to some extent, it's a sign of health) but your way is not the way to do this, IMHO. Best, Faidon On Wed, Jul 22, 2015 at 05:43:07PM -0400, Brian Gerstle wrote: This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com wrote: Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too. GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ 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] I love Parsoid but it doesn't want me
Il 24/07/2015 06:35, C. Scott Ananian ha scritto:
Well, it's really just a different way of thinking about things. Instead
of:
```
import mwparserfromhell
text = I has a template! {{foo|bar|baz|eggs=spam}} See it?
wikicode = mwparserfromhell.parse(text)
templates = wikicode.filter_templates()
```
you would write:
```
js Parsoid = require('parsoid');
js text = I has a template! {{foo|bar|baz|eggs=spam}} See it?;
js Parsoid.parse(text, { document: true }).then(function(res) {
templates = res.out.querySelectorAll('[typeof~=mw:Transclusion]');
console.log(templates);
}).done();
```
That said, it wouldn't be hard to clone the API of
http://mwparserfromhell.readthedocs.org/en/latest/api/mwparserfromhell.html
Parsoid's expressiveness seems to convey useless information, overlook
important details, or duplicate them in different places.
If I want to resize an image, am I supposed to change data-file-width
and data-file-height? width and height? Or src?
I think what I'm looking for is sort of an 'enhanced wikitext' rather
than 'annotated HTML'.
and that would probably be a great addition to the parsoid package API.
HTML is just a tree structured data representation. Think of it as XML if
it makes you happier. It just happens to come with well-defined semantics
and lots of manipulation libraries.
I don't know about edits tagged as VisualEditor. That seems like that
should only be done by VE.
All edits made via visualeditoredit
https://www.mediawiki.org/w/api.php?action=helpmodules=visualeditoredit
are tagged.
I take it you would like an easy work flow to
fetch a page, make edits, and then write the new revision back?
Right.
mwparserfromhell doesn't actually seem to have that functionality
It is actually pretty easy to do with Pywikibot.
But since Parsoid happens to work server-side, it makes sense to request
and send back the structured tree directly.
, but it
would also be nice to facilitate that use case if we can.
--scott
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for your time.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Brad Jorsch - Senior Software Engineer
Hooray! Looking forward to his next evolution :-) Il 09/07/2015 19:38, Bryan Davis ha scritto: I'm pleased to announce that Brad Jorsch has been promoted to Senior Software Engineer. Brad joined the WMF in October of 2012 as a member of the MediaWiki Core team under RobLa [0]. Prior to joining the WMF, Brad was a strong contributor in a volunteer capacity both on-wiki and via code contributions. He has community earned admin rights on enwiki and his bots (AnomieBOT, AnomieBOT II, MediationBot, MedcabBot, ...) have made over 1.8 million edits on project wikis [1]. His community contributions led directly to his recruitment and hiring following the 2012 Berlin Hackathon. During his tenure at the WMF, Brad has become the de-facto owner of the Scribunto extension and the primary maintainer of the MediaWiki web API (api.php). During the 2014-2015 fiscal year, Brad has focused primarily on the MediaWiki web API (api.php). This largely solo project has included writing an RfC [2] and working on implementation not only in MediaWiki core but also across many affected extensions. Recent improvements have included JSON format updates [3] and the simplification of continuation mode processing for clients [4]. I look forward to working with Brad on the Wikimedia Reading Infrastructure team to continue stewardship of the MediaWiki web API [5] and expect to see continued excellence from his MediaWiki and Wikimedia contributions. [0]: https://lists.wikimedia.org/pipermail/wikitech-l/2012-October/064120.html [1]: https://tools.wmflabs.org/guc/?user=AnomieBOT [2]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap [3]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-May/82.html [4]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-June/84.html [5]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-May/081648.html Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I love Parsoid but it doesn't want me
The slides are interesting, but for now it seems VisualEditor-focused and not nearly as powerful as mwparserfromhell. I don't care about presentation. I don't want HTML. And I hate getting all edits tagged as VisualEditor. Il 23/07/2015 22:02, C. Scott Ananian ha scritto: HTML5+RDFa is a machine-readable format. But I think what you are asking for is either better documentation of the template-related stuff (did you read through the slides in https://phabricator.wikimedia.org/T105175 ?) or HTML template parameter support (https://phabricator.wikimedia.org/T52587) which is in the codebase but not enabled by default in production. --scott ___ 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] I love Parsoid but it doesn't want me
Well, it's really just a different way of thinking about things. Instead
of:
```
import mwparserfromhell
text = I has a template! {{foo|bar|baz|eggs=spam}} See it?
wikicode = mwparserfromhell.parse(text)
templates = wikicode.filter_templates()
```
you would write:
```
js Parsoid = require('parsoid');
js text = I has a template! {{foo|bar|baz|eggs=spam}} See it?;
js Parsoid.parse(text, { document: true }).then(function(res) {
templates = res.out.querySelectorAll('[typeof~=mw:Transclusion]');
console.log(templates);
}).done();
```
That said, it wouldn't be hard to clone the API of
http://mwparserfromhell.readthedocs.org/en/latest/api/mwparserfromhell.html
and that would probably be a great addition to the parsoid package API.
HTML is just a tree structured data representation. Think of it as XML if
it makes you happier. It just happens to come with well-defined semantics
and lots of manipulation libraries.
I don't know about edits tagged as VisualEditor. That seems like that
should only be done by VE. I take it you would like an easy work flow to
fetch a page, make edits, and then write the new revision back?
mwparserfromhell doesn't actually seem to have that functionality, but it
would also be nice to facilitate that use case if we can.
--scott
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Changes require Verified+2 to be merged by CI
Le 22/07/2015 18:28, Antoine Musso a écrit : The task is: https://phabricator.wikimedia.org/T106531 Will give it a shot tomorrow. I got stomped with other task in the morning and by the time I had the new Zuul package ready, it was already SWAT deploy. So the fix is further delayed to Friday European morning which is almost not a Friday deploy :-} -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I love Parsoid but it doesn't want me
HTML5+RDFa is a machine-readable format. But I think what you are asking for is either better documentation of the template-related stuff (did you read through the slides in https://phabricator.wikimedia.org/T105175 ?) or HTML template parameter support (https://phabricator.wikimedia.org/T52587) which is in the codebase but not enabled by default in production. --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Min php version
On Thu, 23 Jul 2015 12:19:13 +0200, bawolff bawolff...@gmail.com wrote: Just for reference, in this case, I'm pretty sure the code in question has unit tests Yes, it does. (For posterity, my example was commit 5042d260ce5190cce0c325b7cb5b618b3cff73bc, which fixed 5.3 compat breakage caught by 5ed35b04c99abbd7a8d015402f359c7002c491eb, a regression from aa00a3e8384a87430f82739507e09bb74c6b40ec. All three commits in this case were my own.) -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
Le 22/07/2015 13:39, Petr Bena a écrit : Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too. There are a few reasons for not using GitHub that I keep mentioning: * We need a reliable git services we can act on with minimum latency. The reason we migrated out of SourceForge svn was because of some hours of outage that prevented us from fixing the live site. * The GitHub term of services [1] has a few restrictions that prevent some our community members from contributing: ** You must be 13 years or older to use this Service. ** You must be a human. Accounts registered by bots or other automated methods are not permitted. At one point I think they requested you to put your real name. [1] https://help.github.com/articles/github-terms-of-service/ But the real reason is why rely on a 3rd party when we can do it ourselves? Lot of old timers feel we should self host as much as possible. The GitHub's pull requests are more compliant with original git philosophy of Linus, see this video: https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient replacement to our current git-review mechanism, which is very complex and unfriendly to new developers who probably find it very difficult to use. I haven't watched the hour long video but I can quite a comment from Linus explaining why he would not honor pull requests on the linux GitHub project: -8-8-8-8-8- Linus wrote: I don't do github pull requests. github throws away all the relevant information, like having even a valid email address for the person asking me to pull. The diffstat is also deficient and useless. Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version. As a result, I consider github useless for these kinds of things. It's fine for *hosting*, but the pull requests and the online commit editing, are just pure garbage. I've told github people about my concerns, they didn't think they mattered, so I gave up. Feel free to make a bugreport to github. -8-8-8-8-8- So in short the pull requests merge are quite awful and drop most of the context. Git built-in mechanism is http://git-scm.com/docs/git-request-pull Original: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 Linus followed up with more details in subsequent replies. If you don't like git-review, which we borrowed from OpenStack and serves thousands of professional developers there, feel free to amend it or create your own wrapper on top of git push refs/for/branch -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
Brian Gerstle wrote: I'm writing with plans for the Wikimedia iOS engineering team to move its workflow to GitHub with Travis CI, much like RESTbase. The Wikimedia iOS engineers have been maintaining their own CI and build server and using Gerrit for code review. The more time efficient and commonplace approach for open source iOS software development leans heavily on GitHub with Travis CI instead (e.g., WordPress[0][1] and Firefox[2][3]). By using GitHub with Travis CI, the team believes it will work faster, improve testing, grow developer confidence in making code changes, and, most importantly, deploy fewer bugs to production. For builds requiring sensitive information (e.g., prod certs), will continue to run on WMF's Mac Mini. As is done for Android, when betas are pushed, the team will notify mobile-l. Feel free to reply or email me directly with any questions or comments. Hi. Where have you discussed this idea on-wiki or on Phabricator? Is there a request for comments on mediawiki.org or a Phabricator Maniphest task tracking this? Development teams are given fairly wide latitude, but it's pretty difficult to argue against Faidon's position that development teams shouldn't be unilaterally trying to move themselves to other platforms, especially without any kind of proper discussion. iOS is a proprietary operating system that serves a walled garden environment. It's completely unaligned with Wikimedia's values and mission. GitHub may be a better fit for you and your team (though there's no real evidence of this), but the bigger and more pressing problem is that your team shouldn't exist within the Wikimedia Foundation, in my opinion. After years of discussion, I'm still unconvinced that mobile apps are worthwhile. We should instead be focusing resources on killing MobileFrontend and creating a proper mobile experience for our users. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] I love Parsoid but it doesn't want me
Are there any stable APIs for an application to get a parse tree in machine-readable format, manipulate it and send the result back without touching HTML? I'm sorry if this question doesn't make any sense. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
The (rough) epic definition is already on Phabricator: https://phabricator.wikimedia.org/T98970. I've defined some metrics there already, but admittedly—and thanks for calling us out on this—we don't really have baselines*. I think there are some feasible ways to get a rough starting point, which I can brainstorm w/ the team. We were planning (or I should say, I was hoping) to gather more code metrics anyway, so I'm glad to have an excuse to hook it up sooner ;-). FWIW, I also think having patches tested as part of code review https://github.com/bgerstle/apps-ios-wikipedia/pull/3 would also work as a sufficient definition of success. Our goal here is to do that as quickly, easily, and cheaply as possible so we can get back to focusing on the app. * I think it's fair to say that the coverage at point of migration was already low (~10% based on my Travis-covered fork) and hasn't changed much. On Thu, Jul 23, 2015 at 2:04 PM, Greg Grossmeier g...@wikimedia.org wrote: Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: By using GitHub with Travis CI, the team believes it will work faster, improve testing, grow developer confidence in making code changes, and, most importantly, deploy fewer bugs to production. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
quote name=Antoine Musso date=2015-07-23 time=15:35:29 +0200 On the other hand, there are some providers of XCode that are integrated with Github/Travis and grant us everything we need out of the box for free/cheap price. Which we could probably do from Gerrit: https://lists.wikimedia.org/pipermail/qa/2015-July/002323.html From my understanding that would give us: * Gerrit for code review (non-GitHub) * Travis for iOS build/tests What else do we need? Obvious statement: if we go this route, enabling TravisCI integration with a Gerrit hosted project will only be after careful review and approval for situations (like iOS) where our in-house expertise and infrastructure is not sufficient. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikipedia iOS app moving to GH
Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: By using GitHub with Travis CI, the team believes it will work faster, improve testing, grow developer confidence in making code changes, and, most importantly, deploy fewer bugs to production. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
The even shorter answer is: you can't amend other people's pull requests without being explicitly allowed to. Il 23/07/2015 11:57, Brian Gerstle ha scritto: The short answer is: yes. GitHub doesn't have the patch as a concept, only commits, branches, and forks. We only plan on encountering forks when merging volunteer contributions. Regardless of whether it's a fork, your ability to push to a branch co Ed down to whether you're a collaborator for that repo. On Wednesday, July 22, 2015, Ricordisamoa ricordisa...@openmailbox.org wrote: Il 22/07/2015 23:43, Brian Gerstle ha scritto: This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. With GitHub it is not possible to amend other people's patches, is it? We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com wrote: Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too. GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-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] Wikipedia iOS app moving to GH
Il 22/07/2015 12:40, Brian Gerstle ha scritto: Hey everyone, I'm writing with plans for the Wikimedia iOS engineering team to move its workflow to GitHub with Travis CI, much like RESTbase. The Wikimedia iOS engineers have been maintaining their own CI and build server and using Gerrit for code review. The more time efficient and commonplace approach for open source iOS software development leans heavily on GitHub with Travis CI instead (e.g., WordPress[0][1] and Firefox[2][3]). By using GitHub with Travis CI, the team believes it will work faster, improve testing, grow developer confidence in making code changes, and, most importantly, deploy fewer bugs to production. By the way, the Pywikibot team has been using Gerrit Travis CI https://travis-ci.org/wikimedia/pywikibot-core for quite some time. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I love Parsoid but it doesn't want me
Il 23/07/2015 15:28, Antoine Musso ha scritto: Le 23/07/2015 08:15, Ricordisamoa a écrit : Are there any stable APIs for an application to get a parse tree in machine-readable format, manipulate it and send the result back without touching HTML? I'm sorry if this question doesn't make any sense. You might want to explain what you are trying to do and which wall you have hit when attempting to use Parsoid :-) For example, adding a template transclusion as new parameter in another template. XHTML5+RDFa is the wall :-( Can't Parsoid's deserialization be caught at some point to get a higher-level structure like mwparserfromhell https://github.com/earwig/mwparserfromhell's? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
On Thu, Jul 23, 2015 at 2:08 PM, Ricordisamoa ricordisa...@openmailbox.org wrote: The even shorter answer is: you can't amend other people's pull requests without being explicitly allowed to. Which is both good and bad. In gerrit, anyone can amend my patch, potentially obliterating my changes, which means we need to manually sync up to prevent conflicts and erasing each others' work: I'm going to amend OK! Ok I amended! Ok I'm stashing my changes, pulling, and re-applying! As opposed to: I pushed a commit to your branch OK, I pulled the remote changes and had mine automatically rebased on top Different strokes for different folks. Il 23/07/2015 11:57, Brian Gerstle ha scritto: The short answer is: yes. GitHub doesn't have the patch as a concept, only commits, branches, and forks. We only plan on encountering forks when merging volunteer contributions. Regardless of whether it's a fork, your ability to push to a branch co Ed down to whether you're a collaborator for that repo. On Wednesday, July 22, 2015, Ricordisamoa ricordisa...@openmailbox.org wrote: Il 22/07/2015 23:43, Brian Gerstle ha scritto: This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. With GitHub it is not possible to amend other people's patches, is it? We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com wrote: Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too. GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-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 -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
quote name=MZMcBride date=2015-07-23 time=09:54:31 -0400 Where have you discussed this idea on-wiki or on Phabricator? Is there a request for comments on mediawiki.org or a Phabricator Maniphest task tracking this? Development teams are given fairly wide latitude, but it's pretty difficult to argue against Faidon's position that development teams shouldn't be unilaterally trying to move themselves to other platforms, especially without any kind of proper discussion. The previous(ly declined) discussion was at: https://phabricator.wikimedia.org/T95749 Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia iOS app moving to GH
Force pushes can be disabled if you contact github support On Wed, Jul 22, 2015 at 11:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com wrote: Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too. GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks ___ 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] Wikipedia iOS app moving to GH
The short answer is: yes. GitHub doesn't have the patch as a concept, only commits, branches, and forks. We only plan on encountering forks when merging volunteer contributions. Regardless of whether it's a fork, your ability to push to a branch co Ed down to whether you're a collaborator for that repo. On Wednesday, July 22, 2015, Ricordisamoa ricordisa...@openmailbox.org wrote: Il 22/07/2015 23:43, Brian Gerstle ha scritto: This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis). That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means amending patches becomes pushing another commit onto a branch. We've run into issues w/ rebasing amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. With GitHub it is not possible to amend other people's patches, is it? We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit. On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com wrote: Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too. GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Min php version
(Also, that only catches incompatibilities in code that has unit tests. ;) I've ran into 5.3 compat breakages in the past when I added new features with tests, that used some existing code without tests.) Just for reference, in this case, I'm pretty sure the code in question has unit tests --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
