[ruby-core:25356] Re: [Feature #2033] Move Core Development to Git

Below is an edited translation of a conversation about "[Feature
#2033] Move Core Development to Git" on IRCNet's %ruby from Thursday,
September 3rd beteween 10am and 2pm JST. I'm providing this translated
log on behalf of Yugui, and with the permission of the participants.
If nothing else, it will serve as a peek into the opinions of a few
people on the "other side".

== Who ==
- n0kada: aka nobu,  Ruby Committer
- unak: aka usa, Ruby Committer (active contributer to the Windows version)
- yugui: Ruby 1.9 Release Manager
- eban: Ruby Committer (active contributer to the Windows version)

== Log ==
unak: [ruby-core:25280] He should have added that "unak doesn't read
English mails"
eban: would anyone actually know who unak is?
unak: true
n0koda: if you checkout win32-unicode-test and still don't know,
there's not much more you can do
unak: I don't think unak appears anywhere in that
n0kada: doesn't it appear in $Author$?
eban: usa
unak: it should be usa
n0kada: so it was usa. whatever
eban: "USA doesn't read English mails." would be surreal
----
eban: everyone seems to love git
unak: if they want to use git they should just use it
unak: why do they have to force it on other people?
n0kada: just git clone git://github.com/shyouhei/ruby.git
n0kada: and just linking that up with git svn should be enough?
unak: I'm pretty sure there was a clear explanation there too
n0kada: so pasting http://github.com/shyouhei/ruby/tree/trunk on the
ticket should close it?
unak: seems like nobody understands that converting the main
repository to git will only directly affect committers, not
non-committers
unak: 1) if you want to play with ruby's source using git, there are
already git repository (miirrors) so you can just do what you like
with them
unak: 2) it doesn't matter if the main repository is CVS or Subversion
or Git, it has nothing to do with any of you
n0kada: i don't think there was an explanation of git svn there...
unak: http://wiki.github.com/shyouhei/ruby/committerhowto
unak: you mean that link?
n0kada: that's the first time I've seen that
n0kada: I pasted that link and closed the ticket
eban: http://wiki.github.com/shyouhei/ruby/noncommitterhowto
unak: I think you should add it to the top of the (Ruby) wiki, but I
guess its fine just as a ticket
----
n0kada: runrun just keeps on talking
n0kada: but not with any arguments I haven't seen before
eban: where are you talking?
n0kada: on talk on freenode
unak: what are you talking about?
eban: git probably
n0kada: #2033
unak: why do they keep on trying to force other people to use git?
n0kada:  <runpaint> Because for it to be successful there has to be a
snowball effect: a couple of people use it, which encourages more
people to use it, which changes the way in which those people are
organised, which encourages more people to use it, etc. A mirror can
be ignored. I'm not saying it couldn't work, merely that the
commenters in that thread supported moving development to Git; not
just a mirror.
unak: can you summarize it to 3 lines?
n0kada: we want to use it so you guys must use it too
unak: i can't see any explanation for why a mirror isn't sufficient
n0kada: I told him to explain that after reopening the ticket
n0kada: that was my reply to his reason
unak: "a mirror won't work. because it won't work."
unak: thats all he seems to be saying
unak: this is getting annoying. We should just close svn.ruby-lang.org
unak: that's basically the situation he's looking for, right?
n0kada: including the official mirror?
n0kada: <n0kada> now usa proposed to open the official mirror and to
close svn.ruby-lang.org :)
n0kada:  <runpaint> :-D Success! :-)
unak: All we need to do now is to get Urabe to say that his mirror is
now "Official" and we're done
unak: So, who exactly benefits from not keeping svn.r.o alive?
n0kada: Who own's  http://github.com/ruby ?
n0kada: that would make it look more official
unak: lame
n0kada: No, I mean the feeling of "official/unofficial"
n0kada: i think that's the problem
unak: and I'm saying that the problem of the "feeling" is lame
eban: then you should just state that and we'll be done
n0kada: I think that was the problem from the beginning, is what I'm saling
unak: so why do we have to do this just to make runrun feel better?
unak: if anything, you should be giving more priority to my feelings
n0kada: I'm sure he just wants to feel better without getting in the way
n0kada: It's true that there are lots of tickets that haven't been dealt with
n0kada: On bottleneck is that Urabe's mirror isn't refreshed frequently enough
unak: That's enough. Let's just close svn.r.o and make Urabe's git
mirror official and announce it and get it over with
n0kada: to close svn...
unak: Refresh frequency is only a problem when you can compare it to
commits. If all you can see is the mirror then it shouldn't be a
problem
yugui: I think that git's ability to stimulate community activity is
proven by the example of rails
yugui: So, I guess its fine as long as it doesn't get in the way of
development on svn?
unak: now that there is already a git mirror, I don't understand what
more they could want.
unak: So if the problem is that they can still see the svn repository,
then we should stopping showing it to them
unak: that's just the logical conclusion I arrived at
yugui: I think that what they are asking for is a way for branches
forked from the git mirror to be merged back into a tree for release
yugui: I'm against relying on commercial services like github
unak: but, I guess it should be enough for now
unak: "a way for branches forked from the git mirror to be merged back
in a tree for release"
unak: What ever you use, some kind of tool will be needed for that
yugui: svn's history and merge information is rather weak
yugui: you lose information
yugui: that gets in the way of managing further forks
yugui: I think its those kind of minor details that adversely affect
the activity of the community
unak: that's enough. please, just go and use git
yugui: I think the problem can be solved by using primary git
repository, and making svn a mirror of that
n0kada: what kind of information is lost?
yugui: n0kada: When you merge, information relating to the merge branch is lost
yugui: and if svn is used as the main repository, the hashes change
when you do a git svn dcommit
lchin: yugui: that problem is partially solved from svn 1.5 onwards
with svn:mergeinfo, though its kind of a hack
yugui: After merging a particular branch, merging other forks of that
particular branch becomes difficult
yugui: by difficult, i mean its basically impossible to do so while
keeping git-style history information from the merge point
yugui: I guess you could just rebase, but I think that communication
cost would kill the community
yugui: I just got a similar request from wycats
unak: In exchange I'll die, just hurry up and change over to git
n0kada: will everything be solved by having an svn mirror?
yugui: I think it would be a good idea to keep svn around as a branch
which offers a high probability of leading to a release
n0kada: releasing directly from git would be problematic
yugui: rather than considering svn as "the main place where releases
come from", considering it as "the branch where there is a high
probability of being merged into the master" makes it easier for other
developers to get into the flow of development
yugui: in that case, all the hard work gets left to the release manager
yugui: comitters who want to keep on using svn can keep on using it
n0kada: but if we get bug reports, how do we even know if its the
branch we know about?
n0kada: dying from just the bug tracking workload would suck
yugui: thats why there is a unique hash
yugui: if you can't identify the branch, you can just reject the bug
report and ask for the details of the branch
n0kada: I guess if we ignore versions compiled from git then...
yugui: I see. If we release from git, then people working on platform
dependency issues could have a hard time of it
n0kada: I don't object to having an entry point for git, and a
separate entry point from svn
yugui: how about you, unak?
unak: what?
yugui: are you ok with having both?
unak: whatever is ok
yugui: "whatever is ok" sounds more like a critical response to me
yugui: is that an objection to the proposal to stop using svn?
unak: I'll just fork it
n0kada: from git?
n0kada: [ruby-core:25309] what do they mean by "svn based tools"?
n0kada: i guess they mean tool/
yugui: I think make-snapshot is the only problem
eban: how about the auto-update of version.h
n0kada: i forgot about version.h
unak: personally, i don't care about "official", so you can do what
you want and just not worry about me
n0kada: the snapshot can just continue to be produced from the svn frontend
n0kada: with r12345 and r12346, its easy to see which is newer, but
with abc1234 and abcd4321 hashes, you can't easily tell which is newer
yugui: I think you'll get used to it
n0kada: I don't think I'll suddenly be able to understand raw hashes
yugui: at any rate, not having unak around will be a problem
unak: I'm sure there won't be any problem
unak: thanks to git, the patches will just roll in
yugui: that isn't a fair response. You know that there are lots of
subtleties with OSes that are really tricky to handle well
yugui: especially with windows, people willing to deal with that
platform are few and far between
unak: if its important, then someone will eventually deal with it
right? It's "open source"
n0kada: whatever the backend for svn is, whether fsfs or git or
whatever, I don't care. But I don't see any good reason to throw away
svn.
yugui: I can't deny that small details like revision number are a
pain, just like how having git mirror svn leads to lots of small,
problematic details that raise the bar for participation
yugui: unfamiliarity with git's collection of commands is another
undeniable issue
yugui: Anyway, could you please add a reply to the ticket about the
lack of a reason to get rid of svn?
yugui: the worst thing to have is a communication gap
----

== END OF TRANSLATION ==

--
Leonard Chin