I am now the project manager for MediaWiki's switch to Git and Gerrit.
I'm working to ensure that we hit the March 21st migration date. I am
prioritizing issues and finding workarounds.
I believe the lack of arbitrary labels/tags on changes is a big workflow
problem.[0] The current workaround is to use "topic branches" (Gerrit
calls them topics; Git calls them branches). To do that, you have to
use git-review. So if you have tried and failed to install and use
git-review, please speak up ASAP so we can make our git-review
instructions and workflow more robust.
And can any of you help make native packages for git-review that work on
Mac and Windows?[1]
Thanks.
[0]
https://labsconsole.wikimedia.org/wiki/Gerrit_bugs_that_matter#Issue_287:_A…
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=35145
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
A Wikipedia page loads. The last thing to load is the banner. This
pushes the page content down. If you've clicked on a link near the top
of the page, the banner grabs it instead.
This happened last year and it was reported then (and it was
incredibly annoying then too). It also fouls up stats on banner
effectiveness, as banners are clicked on without intention to do so.
Please load the page with a space for the banner to avoid this effect.
- d.
I have a parser function #lookup that performs a database query, given a string key. When a wiki page contains {{#lookup:MyKey}}, the callback function looks up the associated value and uses StripState to place it into the article:
$parser->setFunctionHook('lookup', 'lookupCallback'));
...
function lookupCallback($parser, $key) {
$value = bigDatabaseQuery($key);
return $parser->insertStripItem($value);
}
This works fine, but when there are many #lookup calls on a single wiki page, we are making many database calls. So I'd like to collect all the keys from all the #lookup calls and perform a SINGLE database query "where key in ('key1', 'key2', ..., 'keyN')", then call insertStripItem() with each value. I can't seem to figure out how to architect this.
The callback (lookupCallback) is the ideal place to call insertStripItem with the looked-up values, since it places the UNIQ string in the right location in the article. But it also seems to be the only place that I can collect all the keys for performing the single SQL query. This is a chicken-and-egg problem. I can't seem to do the SQL query earlier than lookupCallback because if I do, this logic will run even when #lookup is not present.
Any advice on how to structure this?
Thanks,
DanB
Hi all,
Some disclaimers before I start my thread:
1) I am a big believer in Git and dvcs and I think this is the right decision
2) I am a big believer in Gerrit and code-review and I think this is
the right decision
3) I might be wholly unaware / inaccurate of certain things, apologies
in advance.
4) A BIIGG thankyou to all the folks involved in preparing this
migration (evaluation, migration and training): in particular Chad,
Sumanah and Roan (but I am sure more people are involved and I am just
blissfully unaware).
My main worry is that we are not spending enough time on getting all
engineers (both internal and in the community) up to speed with the
coming migration to Git and Gerrit and that we are going to blame the
tools (Gerrit and/or Git) instead of the complex interaction between
three changes. We are making three fundamental changes in one-shot:
1) Migrating from a centralized source control system to a
decentralized system (SVN -> Git)
2) Introducing a new dedicated code-review tool (Gerrit)
3) Introducing a gated-trunk model
My concern is not about the UI of Gerrit, I know it's popular within
WMF to say that it's UI sucks but I don't think that's the case and
even if it was an issue it's only minor. People have already suggested
that we might consider other code-review systems, I did a quick Google
search and we are the only community considering migrating from Gerrit
to Phabricator. I think this is besides the point: the real challenge
is moving to a gated-trunk model, regardless of the chosen code-review
tool. I cannot imagine other code-review tools that are also based on
a gated-trunk model and work with Git are much easier than Gerrit. The
complexity comes from the gated-trunk model, not from the tool.
The gated-trunk model means that, when you clone or pull from master,
it might be the case that files relevant to you have been changed but
that those new changes are waiting to be merged (the pull request
backlog, AKA the code-review backlog). In the always-commit world with
no gatekeeping between developers and master, this never happens; your
local copy can always be fully synchronized with trunk ("master").
Even if a commit is reverted, then your local working copy will still
have it, and any changes that you might have based on this reverted
commit, you can still commit. Obviously people get annoyed when you
keep checking in reverted code, but it won't break anything.
In an ideal world, our code-review backlog would be zero commits at
any time of the day, if that's the case then 'master' is always
up-to-date and you have the same situation as with the 'always-commit'
model. However, we know that the code-review backlog is a fact and
it's the intersection of Git, Gerrit and the backlog that is going to
be painful.
Suppose I clone master, but there are 10 commits waiting to be
reviewed with files that are relevant to me. I am happily coding in my
own local branch and after a while ready to commit. Meanwhile, those
10 commits have been reviewed and merged and now when I want to merge
my branch back to master I get merge conflicts. Either I discover
these merge conflicts when my branch is merged back to master or if I
pull mid-way to update my local branch.
To be a productive engineer after the migration it will *not* be
sufficient if you have only mastered git clone, git pull, git push,
git add and git commit commands. These are the basic git commands.
Two overall recommendations:
1) The Git / Gerrit combination means that you will have to understand
git rebase, git commit --amend, git bisect and git cherry-pick. This
is advanced Git usage and that will make the learning curve steeper. I
think we need to spend more time on training, I have been looking for
good tutorials about Git&Gerrit in practise and I haven't been able to
find it but maybe other people have better Google Fu skills (I think
we are looking for advanced tutorials, not just cloning and pulling,
but also merging, bisect and cherrypick).
2) We need to come up with a smarter way determining how to approach
the code-review backlog. Three overall strategies come to mind:
a) random, just pick a commit
b) time-based picking (either the oldest or the youngest commit)
c) 'impact' of commit
a) and b) do not require anything but are less suited for a
gated-trunk model. Option c) could be something where we construct a
graph of the codebase and determine the most central files (hubs) and
that commits are sorted by centrality in this graph. The graph only
needs to be reconstructed after major refactoring or every month or
so. Obviously, this requires a bit of coding and I don't have formal
proof that this actually will reduce the pain but I am hopeful. If
constructing a graph is too cumbersome then we can sort by the number
of affected files in a commit as a proxy. If we cannot come up with a
c) strategy then the only real option is to make sure that the queue
is as Wikimedia short as possible.
Best,
Diederik
Hi,
In SignupAPI extension, should I fire the Ajax user validation (username
available & not illegal checking) 'onchange' / 'onkeyup' ?
1) 'onchange' would cause less Ajax calls but will give result only when
the user has pressed tab or clicks to the next field
2) 'onkeyup' would cause a lot of Ajax calls but would give result as &
when the user types so that he can correct the input if needed rather than
going to the next field & then finding that he just gave some invalid input
in the previous field
What would be better from a UX + Performance point of view? Is there any
other JavaScript event I should be looking at?
Thanks
Akshay
Hello all,
I was wondering if there's a clean way within the Wiki codebase to
generate a history entry for an article without actually modifying the
content. Essentially, from within an extension, I'd like to treat the
history as a logfile for specific events related to the article that
don't actually modify the article.
Thanks,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
I have a following stuff in git log
(from ssh://saper@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples):
commit 28f176ca9ca3767bfa9f0ec219f5fa0c299c5761
Merge: e2513b6 5c50ad6
Author: Demon <chadh(a)wikimedia.org>
Date: Fri Mar 2 13:15:54 2012 +0000
Merge "Slight doc change as Git test"
commit 5c50ad62ebdee790735a29338aaec7bd9ad2c366
Author: jarry1250 <jarry1250(a)gmail.com>
Date: Thu Mar 1 21:03:19 2012 +0000
Slight doc change as Git test
Change-Id: I2b646e25ece2a0e16f960628e256828a2e020324
commit e2513b6edecf491e5dde1baa999627f9012386eb
Author: cmcmahon <cmcmahon(a)wikimedia.org>
Date: Wed Feb 29 14:03:41 2012 -0700
set up new laptop
Change-Id: I6d99a2c2dcc4a78ac2f8359c6aadbec52dc58dd6
It seems that ^demon is allowed to commit without
a "Change-Id" Fine.
I'd like to fetch the patches related to jarry1250 commit:
$ ssh -p 29418 saper(a)gerrit.wikimedia.org gerrit query 5c50ad62ebdee790735a29338aaec7bd9ad2c366 --patch-sets
change I2b646e25ece2a0e16f960628e256828a2e020324
project: test/mediawiki/extensions/examples
branch: master
id: I2b646e25ece2a0e16f960628e256828a2e020324
number: 2913
subject: Slight doc change as Git test
owner:
name: Jarry1250
email: jarry1250(a)gmail.com
url: https://gerrit.wikimedia.org/r/2913
lastUpdated: 2012-03-02 13:15:54 UTC
sortKey: 001b6f1b00000b61
open: false
status: MERGED
patchSets:
number: 1
revision: 5c50ad62ebdee790735a29338aaec7bd9ad2c366
ref: refs/changes/13/2913/1
uploader:
name: Jarry1250
email: jarry1250(a)gmail.com
type: stats
rowCount: 1
runTimeMilliseconds: 511
so I can now
$ git fetch ssh://saper@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples refs/changes/13/2913/1
>From ssh://gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples
* branch refs/changes/13/2913/1 -> FETCH_HEAD
$ git checkout -b r2913 FETCH_HEAD
Switched to a new branch 'r2913
Now let's try the same with ^demon's commit:
$ ssh -p 29418 saper(a)gerrit.wikimedia.org gerrit query 28f176ca9ca3767bfa9f0ec219f5fa0c299c5761 --patch-sets
type: stats
rowCount: 0
runTimeMilliseconds: 429
It's just not there...
Same with another one:
$ ssh -p 29418 saper(a)gerrit.wikimedia.org gerrit query 17f028f7d0b73b777cc2a06d99b3538d2c95db09 --patch-sets
type: stats
rowCount: 0
runTimeMilliseconds: 429
Even if I listen all abandoned changes in the project:
$ ssh -p 29418 saper(a)gerrit.wikimedia.org gerrit query status:abandoned project:test/mediawiki/extensions/examples --patch-sets > r1
They are not there:
$ grep 28f176ca9ca3767bfa9f0ec219f5fa0c299c5761 r1
$ grep 17f028f7d0b73b777cc2a06d99b3538d2c95db09 r1
Seems like they are totally outside of gerrit. Pretty lame for a "gated trunk"!
//Saper
Hello, everybody. I'm a GSOC student from China. With some development
experience on Android, I would love to work on this project "Improve our
Android application -- integrate with SuggestBot to suggest a mobile task
to a user."[1.]
Could somebody tell me some information, please?
1.Where to download the current Android application? I have searched the
keyword "Android" on the wiki, but can not be sure which is the right page
in so many result pages.
2.Where to see the source code for current Android application?
3.Where to see documents about this project?
4.Who developed the Android application? Is the developer a GSOC student?
And whether will he still work on the project this GSOC?
Wish for your reply. Thanks a lot!
Best Wishes.
--
Yeshow