Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))

On 9/10/07, Kevin Kubasik <kevin kubasik net> wrote:

A few key points:
* There is a _very_ strong general opinion that Gnome should eventually
move to a DSCM system, it is really just a discussion of how and when.
* The 3 systems under consideration are bzr,git, and hg. There has not
been much discussion on which to choose, it is probably better that people
include their experiences with these tools on the wiki page. (please
provide hard numbers to backup statements! Don't just say its slow, give us
a time it took to perform a task! Don't just say it takes up a lot of
space? How much? and preferably, provide comparisons for the other systems
if possible)
* A major concern is allowing our current translation and documentation
teams to continue to work without serious interruption. Many of those
contributers are less technical, or simply have less interest in playing
around with software to figure it out ;). Also, translators don't want an
entire repository to edit one po file, can a single file be checked out
locally and modified? There was even discussion of a web interface, but the
most important thing here is if we were to move to web system for
translations, it would have to _already written_ before any real talk of it
continued. (perhaps Launchpad will have completely open sourced that
component, and we could use their system) But we want to avoid discussions
of vaporware here, if we are going to talk about a program that can do
something for the translators, please present a link to a project we can
use or modify, or some proof of concept code.
* There is a debate over the difficulty of using a new distributed system,
it seems that alot of developers already use a DSCM somewhere else, and as
a result, are quite comfortable with the technical component (although the
social structure for sharing branches we choose etc. could change their
current use)

I think I've taken a bit different  sentiment coming from the discussions on these various lists.  For me,  Federico hit on so many points in his mail [1]  that I think are the real problems we're seeing.

GNOME is not in need of a DSCM or any other kind of new SCM.  For source control, SVN works fine, just like CVS worked fine.  I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling.  What Federico and Havoc have been saying is there is a real issue of control and visibility.  Some of this could be solved with a DSCM or made easier by one, however I think the incorrect approach would be to choose a technology before examining why people are already using it and what kind of impact and benefits it will really have on our community when we all adopt it.

So stepping outside the SCM arguments for a minute and looking at the community issues.  

In terms of source control access, I don't think there should be any strict controls.  I would suggest that we use, or create a system of "invites" in a much similar way to GMail when it first started or most social network systems today.  It should be easy enough for me or anyone else with some kind of repository access to invite someone else to use the central system; I shouldn't have to ask permission of anyone or go through some admin hoops.  There should be am interface that allows me to login, enter the email address of the person I'm inviting into the "GNOME Master (Source) Control Program" and "poof!" they get an email and are allowed access.  I just want to note that I think the people who are doing this work already are working hard and doing great, but I know creating new accounts isn't a good time; it's busy work that's annoying and we should remove it.

Two things are necessary for this kind of loose trust facility, you need visibility and persistent connections.  I could go into more depth, but basically if I invite people into our GMCP who break things, I lose my GMCP access; thus we need to maintain a persistent "who invited who" system.  Also there should be an email list, or RSS feed of who just invited who into the community such that things can't run out of control without other easily people noticing.

You probably also want to think about easy ways to consume other projects.  It seems like GNOME has a history (and maybe this is an artifact of the difficulties described above) of enveloping existing projects, how can we make a transition from one project SCM hosting into GNOMEs smooth and easy?

Now, given all that junk I just spouted up there people should be thinking about if this is a better system; will it allow a more fluid system of community growth and inclusion.  Are there other considerations that need to be taken into account.  Then, once we've decided that that's the type of future we want for our children, and our children's children (despite the fact that children shouldn't be having sex).  We can begin to examine if a DSCM or CSCM can handle that, and which one of those can handle it best; also we can decide if our current system just needs to be changed. 

GNOME is in need of improving things [2] and we shouldn't let debate over choosing a technology fog our sense of what's being improved.

The other part I wanted to rant about slightly is this idea of visibility.  There are a lot of ways to acheive this, and I have ideas of my own that I won't go into now.  However the cvs-commits list was a great thing when the community was small and easy for any person to watch all the traffic.  Now it's a bit larger and there are so many commits happening that I can't be on that list anymore.   I really doubt a type of SCM  is going to make a difference in how this proceeds, however I believe it's something that needs to be addressed not matter what.  You can punt it from this conversation for now, but as a technology is being decided upon, this system needs to come to mind.  I'd like to see what other people are working on, the new projects they start and how they are progressing.  Hopefully it will be easier to put your code into GNOME in the future and we have a way of keeping up with everyone through their commits.  You write code for people to see and read, not for computers; high level languages are for sharing and communicating ideas with each other.

~ Bryan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]