On 22/03/11 20:26, Brion Vibber wrote:
I've started collecting some notes on issues that need to be considered for a potential git migration:
http://www.mediawiki.org/wiki/Git_migration_issues
I'm paying particular attention to the localization workflow thing. Note that TranslateWiki's been working on StatusNet's git repository for some time; git itself isn't a particular problem. But changing the layout of repositories could indeed change how some things need to be done, and we need to make sure we know how to solve whichever problems come up.
I think it's pretty likely that we can work those problems out -- nothing's set in stone yet, and there's plenty of opportunity to experiment with some sample layouts first!
Tools are almost never an issue. We could as well use Bugzilla as a patch/review queue and have ONE release manager to apply them in a CVS tree. I have seen developers using MS Word to track code, they even managed to merge their code this way.
The issue we have is a proper workflow and, I believe, the lack of a roadmap.
Do we really need all the language messages in core? They are probably "useless" for day to day code hacking. Most developers probably use the English messages only anyway. The only things we have to do is to fill up the Messages.inc metadata file, and the English message. Nowadays, I do not even bother to translate my own messages to my native language (which is French).
So, to me, messages serves no need for the developers. They are only useful for live site and MediaWiki releases.
For the live site, we could just pull messages from whatever system is used (gettext .po, rosetta, git, ftp site). This can be done every week, day or hour.
Then comes the need to release a MediaWiki release. This mean you have to sync both projects (code + l10n) and this is not possible while you keep having new messages added in MediaWiki or messages parameters being changed.
That is what I meant by a workflow. We have actors, tasks and responsibilities and eventually end up with a product.
I have said it already: we need a rough roadmap to release a new version. One of the first steps would be: - obviously 'no new features' step . Followed by... - 'no new UI messages' - 'no parameter changes' - 'no messages changes'
This will give time to translators to finish up the messages translations for the release.
The lack of roadmap for 1.18 is probably the same cause that makes our code review queue filled again. It looks a bit like a wiki sandbox, some code (myself included) should never have been sent to trunk.
To conclude, the good point, is that we have 1.17 feature frozen, deployed on live site and it might even get released before this summer. Given the situation back in September 2010: this is a huge accomplishment :-)