Re: Subversion Migration: the importance of maturity.

[Sriram Ramkrishna <sri aracnet com>]

On Fri, May 13, 2005 at 03:59:40PM -0400, Miguel de Icaza wrote:
> Is this checking in a tarball, or checking in the uncompressed tarball
> and managing the resulting binary?

If you're talking about binary deltas, arch/baz can't do that.
It can store binary files.  It's probably not a concern unless you
have large amounts of binary files.  In which you case you might
want to question why they exist in the first place.

However..CVS doesn't do binary files either.  We never needed that
particular feature before.  I know subversion does handle binary
deltas.  I'm not sure it's a killer feature for GNOME since we don't
usually put tarballs into CVS since there is no support for this.
It sounds like you found a feature in subversion you like.  There are
several tools out there that could do this for you.  It might not
be built into baz but it does not need to be since this probably
a corner case scenario and one could build their own tool to do so.

> Does this check every vendor release into its own branch?
> 
> > Well, I know that Debian and some GNOME products are already using Arch.
> > Ubuntu is finishing the deployment to start using it a lot and thus any
> > derivative will use it also (like KUbuntu and Guadalinex)
> > 
> > About others using Arch:
> 
> A very interesting list, but it does not seem to have any large projects
> with hundreds of developers.  

I think you're thinking in a central context rather than in a
decentralized context.  Because it is decentralized it can scale
very large because commits can be done to people's own private
branches not to the public branches.  Morever, development can take
place between developers on their own tree completely bypassing the
GNOME branch altogether.  If anything this model will scale even
greater than subversion and also avoid pitfalls of a centralized
model while emulating one.

For instance, there's been long contention with translators and
developers since they both commit to the same tree and sometimes
mistakes are made that causes administrative pain when fixing
those mistakes.

It would be trivial for the coordinator for each language to commit
to their own private gnome branch (with history) and then have the
maintainer of the module to pull their changes making sure nothing
is broken.  If something is broken, he's free to fix and then push
it to the GNOME arch tree at that point.

Most of the work is done in private branches not in public one.

You avoid all kinds of bureaucratic crap with setting up cvs accounts
and trusting users and so forth by letting them just start hacking
without any preamble.  This takes a load off the sysadmin team
I might add who do not have to deal with cvs accounts as much.
Since creating cvs accounts is really about trust.

It also helps route around busy module owners who might not have
time at the moment to look at everything.  They might be able to
annoint another person to serve as a gateway so that they can commit
to that person's branch while you're away on vacation or something
rather than letting it queue up until you get back.

You made an earlier point about tools.  I agree that tools aren't
quite mature.  But arch metadata format is pretty easy to parse since
it came from shell roots.  By adding large open source projects
like ours tools would be forthcoming because the developer base
would potentially rise.  You already have a whole distro using it...

> > > > Arch has also developers working on it at full time.
> > > 
> > > Lets get numbers: how many.
> > > 
> > > Subversion has 8 full time employees that have been working full time
> > > since 2000, and they are employed by Collab.NET that specializes on
> > > this. 
> > 
> > I don't have those details, sorry.
> 
> I think it is a very important feature if we are talking about moving
> something as delicate as GNOME to use a new source code control system.
> 
> This is not a trivial discussion and not one that can be easily reworked
> later on.

We aren't talking about switching we are talking about a limited
time demo to see if a decentralized model is appropriate for GNOME.
Surely, we can agree to do this, right?  Allow people to play with
it and see if it's the right thing?  Stress test, etc etc.  That is
the right conservative approach.  Blindly going with another system
merely because perceived greater community and support isn't doing
anybody any favours since we don't always pick our internal technology
that way anyways.

You're current approach smacks of "business decision thinking"
because your approach is exactly what mine would have been being part
of a very conservative computing environment myself who also worries
about scaling and stability.  Just an observation not a complaint.
You might consider that these arguments have been used by IT managers
in the past when it came to using Linux.  What it does encourage
is a business opportunity which I'm sure you're well aware of.

One might add that several GNOME hackers like JamesH who are in
regular contact with baz developers.  So it isn't like we don't have
a direct line of communication with Bazaar developers.

You should also not ignore the fact that Canonical's Ubuntu uses
GNOME as it's primary desktop and probably has an interest in making
sure that GNOME functions well with Bazaar/Arch.

If you're looking for discussion points on baz/arch.  I'll probably
can list these possibly based on it's technical and social merits:

* Neon library bugs, it's an external dependency that we don't have
  control of.

* Bazaar is changing rapidly and rapid changes can be inherently be
  destabilizing if one does not have good control by checking against
  a vigorous test suite.  We do see a decent bug and issue tracking
  system against bazaar (can't speak for tla)  They might even have
  that but really this is the kind of questions we should be asking.
  UTF-8 support is probably important.  Are bugs fixed quickly?
  How many bugs are against baz?  Tla 1.3 is a more conservative
  project which moves much more slowly but it's interface is a
  lot more opaque and definitely creates a negative reaction with
  some developers.

* Confusion between people using tla 1.3 and bazaar and possible interop
  issues or even interop issues between versions of bazaar. (command line
  options changing etc

* Possible future format changes that could create problems with older 
  branches.

* No way to remove branches having once been created.  Not sure if thats
  a big problem here or not.  But it might be in terms of housekeeping.

* Managing disparate branches might be difficult without having
  a system to publicized and removing common archives.  As branching
  is cheap there will be a lot more branching going on and managing
  might be something we have to think about.  We could involve
  a maze of branches and confusion if we have no discipline.
  Especially if it happens in the GNOME source tree rather than on
  private branches.  People not understanding how de-centralized VCS
  works will fall into this trap.

* Bazaar is painful to build on non-free platforms.  As a cross
  platform desktop project, those of us who (possibly) support
  GNOME on architectures like Solaris, HPUX and AIX will have
  problems since it's not easy to compile on those architectures.
  Sun is supported somewhat but it's not all there.  This could be
  an issue with Sun developers who pull off of our tree for JDS.
  Bazaar/Arch/Monotone needs to be available on every platform
  we support.  Probably should check that it's doable.

Guarantees of format stability and that support for older options
over a long period of time is probably required.  I'll tell you
that I've been playing around with Arch in some form for about 5
years or so.  I've never really had a problem with incompatiblity.

Most of my experiences have been using baz at work on my own coding
projects and talking with arch people about various issues I've
encountered.  I hope this is a balanced observation on arch.   My two
cents.

sri
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers