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 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
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
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
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
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()
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 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
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 =
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
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)
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
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
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
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
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,
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:
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
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
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
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
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
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
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
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
(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
26 matches
Mail list logo
