lilypond-devel
[Top][All Lists]
Advanced

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

Re: we now have "lilypond" organization on GitHub


From: David Kastrup
Subject: Re: we now have "lilypond" organization on GitHub
Date: Wed, 18 Sep 2013 09:46:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Jan Nieuwenhuizen <address@hidden> writes:

> Urs Liska writes:
>
>> You are doing code reviews through a web interface already, isn't it?
>> And this is because that's a quite natural way to communicate, comment
>> on code etc. You can't do _that_ with plain Git.
>
> To me, this is one the most unnatural and therefore annoying parts of
> current development.  I would much rather use git the way it was
> designed and used by its designer and many other free software projects,
> email patches to this list and review through email.

Well, it facilitates looking at stuff in context (though that's fairly
trivial to do by actually applying the patch in a cloned repository, and
in-file-system clones of git repositories are _really_ cheap).

It's pretty lousy for actually incorporating the feedback which, to be
fair, is mostly due to Rietveld not being made for Git.

Comparing the amount of code actually getting reviewed and the amount of
development getting done, the Linux kernel does not seem to suffer all
that badly from working with a patch/mail-centric workflow.

Of course there are some reasons that don't hold for us: Linux uses a
single-gatekeeper model (but a project like Git itself is still pretty
active), and Linux employs a fanned-out hierarchical workflow as opposed
to the flat hierarchy the web interfaces allow.

We definitely need good issue tracking (which we doe via Google code).
In contrast, I'm not so sure we are having a lot of net benefit from the
Rietveld review setup.  It's complex, and it's particularly a turnoff
for actual programmers who want to apply their existing skills.

The one area where I'd consider a web interface a possibly good tradeoff
of matching tools to skills would be translation work: that could/should
be a lot more crowdsourced than it is now.  It turns out that organizing
and tracking incremental translation work requires being able to work
with various scripts and stuff: the translation workflow does not
benefit from web-based tools at all.  As a consequence, we have at most
one translator per language.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]