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

[Olav Vitters <olav bkor dhs org>]

Really nice to see these thoughts/suggestions!

On Tue, Sep 11, 2007 at 11:41:28AM -0400, Bryan Clark wrote:
[..]
> 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;

So in short term, I hope it will come close to this. Existing
maintainers will approve the request, then accounts team does a quick
once-over. Ok, it is not everyone, but I assume you at least know the
maintainer.
And instead of Mango sending an invite, the maintainers says: "hey, goto
Mango and fill in the form" 

I do like it for new projects. Although GNOME is not sourceforge (we
cannot host such numbers of projects), some kind of invitation/voucher
system would be nice for new projects. E.g., you see a nice project and
you can somehow invite that project to GNOME. New projects will actually
have a worse experience in the beginning of the new Mango.. I haven't
found a solution (mainly lots of things to setup.. often every project
is handled differently).

> 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

For new projects I assume? I know some maintainers will be annoyed if
you do not ask them before adding an SVN account. In practice, people
can commit anywhere, and that is also something to be careful of (e.g.,
sf has it easier because the access is limited to just one project).

This is also for translations.. if it doesn't go via a coordinator (at
least initially) you get bad translations.

[..]
> 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.

Doesn't exist, but I thought about adding it. IIRC Debian has something
that logs this info; I hope to first get basic stuff into Mango, then
make more use of LDAP.

> 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.

Agreed. I wanted to put something like this in the new SVN email, but I
need to discuss it first. Within Bugzilla they are doing introductions
on the devel list. IMO whenever someone gets an SVN account I'd like to
see it. So something like:
 * Mango sends mail to d-d-l
 * Mango suggests in email that 1st task of the person is to introduce
   himself on d-d-l

IMO this belongs perfectly on d-d-l. Although the mango mail should go
to the best mailing list. E.g., maybe d-d-l, maybe gnome-i18n, maybe
evolution-hackers (project specific is hard).

> 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?

That is always hard. This requires getting a svn dump (sometimes
requires conversion using tailor from another SCM system), then deciding
on new SVN account names, then rewriting SVN dump to have the SVN
account names correct (which ehr, I use vim for).

[..]
> 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

Please expand... long term goals are great! (implementation can take
longer than wanted)

> 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.

I have no idea on how to do this... if the number of commits are too
great, a Planet wouldn't help. So it should hide/group/combine the
boring stuff and show the interesting things. If someone can come up
with the details, ... :)

-- 
Regards,
Olav