Re: GNOME git repositories?



On 12/27/06, Kalle Vahlman <kalle vahlman gmail com> wrote:
2006/12/27, Danilo Šegan <danilo gnome org>:
> I am against having more than one way of accessing source code for
> GNOME source code.  It's as simple as that.  For the benefit of
> translators, documentors, artists, and heck, even developers (imagine
> this: to install GNOME, get gnome-panel using bzr, gtk+ and glib using
> git, nautilus using SVN, ...).

Or imagine installing other dependencies (like cairo) from git. That
would be a mess.

For a very long time, jhbuild was basically broken because Cairo
migrated to git.

Oh, wait!

I think the existing build systems (jhbuild, garnome) cope with the
situation relatively well and if not, they should be fixed. And for
non-developer(ie. coder) input there really should be a more
user-friendly interface anyway, regardless of what SCM is in the
bottom (and it shouldn't matter, this is open source right? We can
make things work together!).

How? I don't see how a more user friendly interface could remove all
the complexity that is created by using many different SCM:s. Jhbuild
can checkout projects from many different types of SCM:s, but it can't
produce diffs, inspect change sets in the repository or any of the
many other SCM-specific daily tasks that one might want to do.
Regardless of how good jhbuild and garnome is, adding more SCM:s
increases the complexity.

I don't want to have to learn about X number of SCM-systems just
because the GNOME community can't decide which SCM is best. Aspiring
GNOME developers shouldn't have to read the svn book
(http://svnbook.red-bean.com/) AND the (still non-existent) bzr book,
git book, mercurial book and darcs book.

By the same token, I don't want to have to learn about 124124
different C coding styles and that is why we have the GNOME Coding
Style (http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html).

I hope people will realise that it doesn't matter what tool (or coding
style) is the best. What matters is keeping the barrier to entry low
and to reduce the amount of annoyances developers has to go through.
Having one SCM keeps things simple and that is good.

--
mvh Björn



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