[Top][All Lists]

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

bug#19883: Correction for backtrace

From: David Kastrup
Subject: bug#19883: Correction for backtrace
Date: Fri, 27 Feb 2015 11:18:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> David Kastrup <address@hidden> skribis:
>> Three years ago in August there was a meeting of developers at my house,
>> a lot of information was passed around and in a concerted effort
>> LilyPond-2.16.0 was released.
>> Since then all developments would properly be labelled a one-person
>> project or side-project.
> OK.  I viewed LilyPond as a project with more people involved.

There are a number of them involved, but with regard to coding,
everybody is working on his own projects.  The largest amount of
"teamwork" is probably done in the translation team (which translates
documentation and web pages to several different languages) and with
documentation writers.

There are also people compiling the releases and running the test
suites.  And there is feedback on the bug trackers.

> Sure.  There’s quite a number of names showing up in the
> lilypond-devel archive though.  We need them to feel concerned about
> this.

The only concern you'll get is people piping up and saying they cannot
believe that not more progress has been made.  Which is not all that
dissimilar to what I see with GUILE and other projects even when sending
ready-made patches.

In this particular case however, the respective people do not have the
low-level skills to actually contribute significantly.  Which is the
reason I try to condense the ugly stuff into well-encapsulated and
controlled places instead of keeping them distributed across the code

The memory management stuff is of that "nobody else treads here" kind.

Now the encoding stuff is wildly enfuriating in its pointless erection
and shifting around of road blocks for people needing to actually work
with strings and buffers in their original encoding, but would possibly
be suitable as material to fight with to more C programmers.

David Kastrup

reply via email to

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