On 11-03-23 01:28 AM, Niklas Laxström wrote:
On 22 March 2011 18:00, Ævar Arnfjörð
Bjarmason<avarab(a)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
- 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]