On 9/10/07, Kevin Kubasik <[EMAIL PROTECTED]> 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

[1]
http://mail.gnome.org/archives/foundation-list/2007-September/msg00059.html
[2]
http://mail.gnome.org/archives/foundation-list/2007-September/msg00004.html
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to