Re: we now have "lilypond" organization on GitHub

[Joseph Rushton Wakeling]

On 24/09/13 13:58, David Kastrup wrote:
> Well, the usage conditions prohibit mimicking them, but then I have my
> doubts that this will stand before a court.  So the worst that can
> happen realistically is that they kick you out.  Which they can for any
> reason at all anyway.

Hmm, I'd like to see the day when they start trying to enforce that condition. 
:-)

> The git-cl work was genuinely necessary for making it tolerable for
> command-line people to deal with the web interfaces of Google Code
> chosen for hosting and maintenance of the issue tracker, as far as
> I understand.
>
> You go mad if you have to do serious amounts of stuff in the "as
> intended" way without it.
>
> [... snip ...]
>
> So how do you set up Google Code properly?  It's always easy to blame
> people for the things they had to do in order to work with the limited
> options available in the past.

No, I understand that it was a workaround for limited options.  What I don't 
understand was why, when faced with the need to make that workaround, the 
reaction wasn't, "This is an unacceptable complication given the functionality 
available elsewhere, we need to find new platforms."

Again, I don't mean to sound intolerant, but it seems to me that many issues 
with Lilypond (and particularly contributing to Lilypond) derive from 
workarounds built on top of workarounds built on top of workarounds.

That kind of situation is very easy to get used to and creates a lot of 
unnecessary difficulty for newcomers or occasional contributors.

> Heh.  Are you sure you have an accurate view of what Savannah is and
> does?

Not at all sure.  Happy to be educated. :-)

My impression was that it's a code-hosting and issue-tracking service dedicated 
to GNU projects, but I have never used it and so know nothing of the details.

I do seem to recall that they were very slow at getting set up to work with git, 
bzr, and other DVCS's.

> The main obstacle is not making decisions but rather putting in the work
> required to follow through with them.

What I'm getting at is that I don't see any detailed summary of pros, cons and 
how-this-will-work that might form the basis of a decision.

For example: was Rietveld chosen on the basis of a thorough review of the 
code-hosting and testing services available, or was it chosen because it was the 
easy thing to get working with Google Code issue tracking, which you were 
already using?  If the latter, then to my mind that was a workaround rather than 
an optimal decision, and it's obviously resulted in long-term problems (albeit 
that it clearly also fulfilled a need).

What I'm concerned about is that future tool choices take Lilypond away from 
that sort of workaround-on-top-of-workaround situation.  I honestly feel that 
the project will be saved a lot of long-term grief by choices of contribution 
tools that are future-proof, easy to use and easy to leave, rather than just 
something that most readily fits with the current setup.