On 12/10/2013 06:41 AM, Carl Peterson wrote:
On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon <[email protected]
<mailto:[email protected]>> wrote:
Hey all,
I recently e-mailed the development list about multiple concurrent
development versions and I’d like to ask users, especially those
currently using the development version, to take the time to
respond to a question regarding the proposal.
If lilypond.org <http://lilypond.org> were to propose multiple
development versions (say 5 instead of 1), each offering a
different set of experimental features (including the canonical
development version), and if lilypond.org <http://lilypond.org>
offered information on which versions were in need of testing by
what types of users, would you be interested in helping out by
doing some typesetting with these alternative versions?
The problem I see is an issue of mixing and matching. What if there is
a feature I want to use on Development Version A and one I want to use
on Development Version B, within the same score? I also foresee a
multiplication of the issues regarding who is using what version on
this list, as in:
Today:
A: "I have this problem. I am using version 2.17.3"
B: "We fixed this problem in 2.17.23"
With multiple versions:
A: "I have this problem. I am using version 2.19.A.3"
B: "This was fixed on version 2.19.B"
A: "Okay, that fixed that, now I have this problem."
C: "This was fixed on version 2.19.C"
A: "I'm confused. How do I fix both of these problems?"
From the perspective of a light-duty user and former patch nanny,
Mike's idea seems quite frankly alarming. The thought of exposing users
to multiple diverging and possibly incompatible development versions of
a system, which is already so complex that modifying the build system
has been called "poking a hornets nest with a stick", would anchor me
quite firmly on latest stable, and I likely wouldn't try to answer
questions on -user, either. I'm quite happy building the binaries and
doc from git, but if the development efforts get even more fragmented,
with devs each competing to get users testing their latest brainstorm, I
doubt it would end well. Yes, of course there are power users who can
handle alpha- and beta-level code, but in the context of trying to make
lilypond *more* accessible to people who simply want to engrave
beautiful music with minimal effort, we would be best served by making
the existing development process more effective and efficient, so that
only code which is truly beta-plus or RC level would be available to users.
For clarity: I'm not saying devs shouldn't fork LP when they want to
work out some cool new feature. Git branches are a fine tool for the
purpose. It's just that there are already so many versions of LP in the
wild that our support and distribution resources are strained, and
introducing another 5 versions of LP, with guaranteed problems, may well
divert developer effort from the main branch or worse, turn the devs and
power users off answering questions and feature requests entirely.
I'm all for exploring options, but I truly believe this adds a level of
complexity we can't handle with existing resources and tools, for
relatively small gains or potential loss of live testing of beta-level code.
Cheers,
Colin
--
I've learned that you shouldn't go through life with a catcher's mitt on both
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
