On Sun, Feb 13, 2011 at 11:18 PM, Siebrand Mazeland s.mazeland@xs4all.nl wrote:
With regards to i18n support it is not clear to me how translatewiki staff would deal with 100+1 commits to different repo's every day if core and extensions would each be in individual repos. Can you please explain how Raymond would be working with Windows and Git in the proposed structure updating L10n for 100 extensions and MediaWiki core? How would translatewiki.net easily manage MediaWiki updates (diff review/commits)?
I'm also an advocate for each extension getting its own git repository, but I'm not sure how this would work, to be honest. It is definitely something we'll need to consider. We appreciate the work that you all do, so I'd hate to make life harder for you. If we go this route, we'll need to make sure we figure out a mitigation strategy here. Thankfully, I believe there is one (more below)
Source code management is now centralised, and correct me if I'm wrong, but we encourage developers to request commit access to improve visibility of their work and grow the community. "Going distributed" in the proposed way, would hamper that, if I'm correct. I think the relative lower popularity of extensions that are maintained outside of svn.wikimedia.org are proof of this. I am not in favour of using GIT in the proposed way. I think core and extensions should remain in the same repo. Checkout are for developers, and developers should get just all of it.
DVCS systems like Git really don't operate well on repositories as large as the full MediaWiki repository. Furthermore, most developers only work with core + a few extensions, so I don't think it's fair to force everyone to check out the full mess.
Riffing on Diederik's suggestion, Git also has the concept of submodules: http://book.git-scm.com/5_submodules.html
I'm betting we'll be able to use submodules to make life better for translatewiki developers.
Rob (p.s. Diederik: I think Git submodules actually predate Mercurial submodules, if memory serves me correctly)