On 22 March 2011 18:00, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
I think you're missing the point that there's no reason why 400 commits should be harder than 1 in this case.
Thanks to Ævar I realised that we're all missing the point and assuming things which are never spoken out. These silent assumptions must be spoken out to get everyone on the same line.
For twn it's not the commits which is hard, it's all the other things: 1) picking up new projects when they are committed (Mediawiki-svn list) - add few lines to our config file - initial import of messages 2) following changes (Mediawiki-svn list) - import new/changed - run fuzzy if needed - bully developers if needed (Code review, IRC)
Now, when we move to git how do we keep the workflow as simple as it is now? Where will the repos be? Will they all share user accounts? Will everyone be able to commit everywhere? How is the standard repo location & file layout enforced? What will we offer to people who check out all extensions from svn and want to update them all in one command? What about only a subset of extensions (extensions used in twn)? What about only the checkout of i18n files (extensions translated in twn)? How do we know when repos are created or deleted? How do we know which repos are the official upstreams and not just clones of extensions developed elsewhere?
What will replace Mediawiki-commits list and code review? It's really hard to say what could be the real issues when there is no proposal how it would actually work. For example I don't think what avar said to me on IRC (below) has been stated here before, while I find it essential to judge the whole idea.
avar> We're not going to move from a "central" SVN server to Git repositories scattered all over the place, just Git repositories hosted on some WM server. avar> So all the ssh keys etc. would already be set up, and getting a list of repos would be no harder than getting a list of extension dirs today.
What other unspoken assumptions are there?
-Niklas