lilypond-user
[Top][All Lists]
Advanced

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

Re: survey on multiple development versions


From: Urs Liska
Subject: Re: survey on multiple development versions
Date: Tue, 10 Dec 2013 17:29:59 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

Am 10.12.2013 17:10, schrieb Mike Solomon:

On Dec 10, 2013, at 6:02 PM, David Kastrup <address@hidden> wrote:

"Phil Holmes" <address@hidden> writes:

----- Original Message ----- 
From: "David Kastrup" <address@hidden>

If we have branches with personal interests, it must become more
feasible for the respective authors with personal interests to provide
binaries if they consider that a good idea.  Any solution that will only
work via the "Phil, do more" route is not going to scale.

-- 
David Kastrup


I think it would potentially be feasible to have a page with a variety
of builds of single binary types.  This could potentially be managed a
la patchy, but the question is: if we had a set of, say Linux x86
builds to try out, would people bother?

It might make more sense to think about improved ways of creating
stable releases during a continuing development cycle.

Well, that was supposed to be related to that.  Now Mike has chosen to
blast ahead with a solution of his before I or someone else made a
formal exposition of the basic problem.

I don’t think asking users a question is blasting ahead with a solution.  It is a question that will help me better understand how users use unstable versions LilyPond, which in turn will help me understand the problem.

Making formal expositions of basic problems is one way to identify a problem, but it is not the only way.  In a lot of my work, I find that entertaining solutions without a clear understanding of a problem is the best way to understand what a problem is.

With respect to the subject of the e-mail, I’m looking forward to more responses like that of Carl Peterson (thank you Carl).

Cheers,
MS


From the perspective of a user:
I can _imagine_ that I would try out different binaries with specific features. But I can also imagine that this would cause confusion on the user side.
I think to make something like this understandable for users one should have a barrier at least like asking "would you like to beta test? Come in and get experimental features, but understand it's not intended for production use"

Although i understand the idea I'm also not sure if that'l be workable.
I think the incentive to try out such a custom binary would be much higher if I were somehow involved in the issue. Say, a discussion on lilypond-user about the feature, and then the developer says: Hey, I can do this, go to ..., grab a build and test.

As a concrete example: When working on our Fried edition we came to the point where Janek created some patches that were necessary to improve some issues. So I couldn't reproduce the scores anymore. When I asked him if he could give me the custom builds he told me they were around 250 MB in size, and producing something along the lines of a binary release was a much more involved process.
Eventually I managed to set up my system to build LilyPond myself so our problem was solved - but that's definitely beyond the range of regular users that should be addressed with Mike's suggestion.

To come back to your suggestion: If I were asked to test a specific build for some new features I'd surely do that. But when just lurking around on lilypond.org and thinking about downloading something I'm not so sure about that. And I think I'm already more involved as a user than a good part of our 'audience'.
So finally I doubt this would be worth the effort.

I don't have any ideas about how to improve the development cycle, so I can't comment on Phil's and David's discussion.

But of course Carl's suggestion appeals to me because it would lower the barrier to contribute to LilyPond because added material would much less affect the stability of the overall product.
Of course it's not necessarily a plugin system, it could also be a library.
OTOH (equally of course) this would only help for smaller additions that can be completely realized with .scm or .ly files, not the "ambitious additions" you probably had in mind that could be complicated to integrate.

Urs



reply via email to

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