Hi Niklas
Comments inline...
On Sat, Feb 11, 2012 at 1:20 AM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
Since you already are suggesting people to start git repositories, we should prepare the i18n support right now. Translatewiki.net is not ready to handle random git repositories all over the world (nor it necessarily wants to do that). MediaWIki has had very good i18n and l10n including extensions - I don't want to lose that. So we need to plan it now, not when we have hundreds of extensions migrated to git and every one doing the things differently.
Fair enough. I think we should handle new extension directories on a case-by-case basis.
If our commit access is restricted (committing updated translations, but also fixing i18n issues) we cannot do our job properly, which means that we will start dropping support for stuff that doesn't handle i18n adequately.
Which reminds me, does LocalisationUpdate support git?
Not yet: https://bugzilla.wikimedia.org/show_bug.cgi?id=34137
Or Extension Distributor?
Not yet: https://bugzilla.wikimedia.org/show_bug.cgi?id=27812
- As far as Chad knows, none of the gerrit bugs listed in
https://labsconsole.wikimedia.org/wiki/Gerrit_bugs_that_matter are bad enough to block the migration. What, *specifically*, do people hate about gerrit? He needs to know specifics to make decisions that might delay the migration.
I read through almost all of the commit mails. If I need to spend any more time on it or do more clicking around my head will probably explode. This means that I want commit emails with links to review tool, review tool should load fast, display all diffs inline (not hidden behind links or anything) and I should be able to filter commits by path or author. In addition I want to be able to tag commits (for l10n team to review or keeping list of commits I want to deploy to the live site). Any failure to meet these requirements is highly likely to be a blocker for me. Oh and something that signs that this commit has followups that fixes problems in it.
I copied the issues you raised to the "Gerrit bugs that matter" page. I also added a tracking bug to make sure we triage that list: https://bugzilla.wikimedia.org/show_bug.cgi?id=34349
- Chad is trying to get the real git repo up and running ASAP so people
can start doing their real work there. He and RobLa believe we should encourage people to consider SVN indefinitely slushed. If you are going to do large things, they prefer you start doing them in git.
We have been in a slush most of this year already and it has affected the work of our team. We have already started to ignore the slush and will probably do it again.
This comment really bears scrutiny. You realize that Chad isn't going to be able to fix the Gerrit/Git issues above if we're mired in a sea of code review, right? Or fixing bugs introduced because some deprecated feature had to be completely removed *right now*, despite the fact that it wasn't harming anyone to keep it around? It's not like your code is actually going to get deployed if you slow down the process this way.
I think rather than ignore Brion's email here: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/58622/...
...you should respond to it.
On the other hand we probably will migrate our extensions to git among the first ones.
Are extensions used by WMF forced to have the gated trunk model?
This is a good question. I don't see how we can avoid it. Gerrit doesn't work with post-commit review, and we make a point of reviewing the extensions that are going onto the cluster.
How much space do the git repos require? Right now we spend under 500M to support the i18n of three branches of mediawiki and all extensions.
My understanding is that the core repo is about 100M with the full revision history. I don't know what it looks like with all extensions, but I have to believe it'll be manageable.
Rob