On 11-03-23 01:28 AM, Niklas Laxström wrote: > On 22 March 2011 18:00, Ævar Arnfjörð Bjarmason<[email protected]> 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 - Brion mentioned there is prior art in hosting large numbers of git repos. Gitorious' codebase is open-source and can be re-used. Wikimedia could potentially host it's own gitorious for MediaWiki git repos. -- This should probably take care of how to handle giving push access to various people -- Theoretically we would also be able to update our own pubkeys if we re-used Gitorious -- Theoretically this should also make it easier to give anyone who asks a user account with commit access only to their own extension. ie: It should become much easier to get extensions of authors without commit who are currently building extensions using tarballs, external code hosting, or pages on MW.org to commit to a Wikimedia hosted repo which we can also commit to and review. - I'd like to use a standard set of scripts for dealing with repos en-masse. This would allow us to do mass commits as well for code maintenance, rather than only being able to checkout en-masse. We could also make this take extensions themselves into account in ways that'll let us have it only download extension repos of a specific type (extensions in TWN, SMW extensions, extensions listed in a text file list of extensions you want to work with) which would help with the TWN issues. - Sadly checking out i18n-only won't be possible if you're planning to commit. Though, is that really so bad? We might need to do some space comparisons, don't forget that .git and .svn dirs take up different sizes, it's not clear what the difference in space use will be. - Git has update, post-receive, and post-update hooks run on a remote repo that gets pushed to. So it should be trivial to send out updates of new commits to mailing lists. Gitorious might also have something to help. -- And if we're using Gitorious and for some unforeseen reason that probably won't happen have to use some ugly hack, at the very least it should be possible to create a dummy user, give him an e-mail of the mailing list, and abuse Gitorious' favorites system to have e-mails sent through that.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
