Re: survey on multiple development versions
Hi 2013/12/10 Mike Solomon m...@mikesolomon.org: 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 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 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? As far as beta-testing is concerned, please consider http://lists.gnu.org/archive/html/lilypond-devel/2013-08/msg00305.html Together with Lilydev this makes trying out experimental features easy enough for non-programmers (quite involved, but easy). I don't understand why that email was ignored :( The script can even handle rebasing features from one version to another. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
survey on multiple development versions
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 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 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? Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon m...@mikesolomon.org 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 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.orgoffered 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? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Dec 10, 2013, at 3:41 PM, Carl Peterson carlopeter...@gmail.com wrote: On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon m...@mikesolomon.org 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 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 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? The idea is that the canonical version will pick up all inclusion-worthy features a few weeks / months after the experimental versions. It is true that it’s annoying to wait, but the current state of things is for these features either to not exist at all or exist at a much later date. I think that the scenario you describe above, while frustrating, is preferential to the current state of things. 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?” The versions are always “branched off of canonical development, like so: canonical development |— A |— B |— C Think of canonical development as a foundation for A, B and C. This means that any bugs fixed in the canonical version will be fixed in the experimental one unless the experiments are so experimental that they break everything, which we’d obviously try to avoid. Conversely, a problem in branch A will never be fixed in just branch B - it will first be fixed in A and then applied to all of the branches (or it will persist in all the branches if no one catches it). Let’s assume that canonical devel is at 2.19.23. You are using 2.19.3.A. It would go as follows: A: I have this problem. I am using version 2.19.3.A” an appropriate response would be either: “This was fixed with version 2.19.23.” or “This was fixed with version 2.19.23.A” but never “This was fixed with version 2.19.23.B It is true, though, that attentiveness to versioning would become important for testers and responders alike. Cheers, MS___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
- Original Message - From: Mike Solomon m...@mikesolomon.org To: LilyPond Users lilypond-user@gnu.org Sent: Tuesday, December 10, 2013 1:23 PM Subject: survey on multiple development versions 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 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 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? Cheers, MS ___ It seems to be fixing a problem we don't have. What would be the benefit? I would also mention that, for this to work, there would need to be parallel documentation streams, too - otherwise users would read the docs for A, assume it's in B and rightly complain if it wasn't. This would entail 1) even _more_ confusion about which is the right doc set to read and 2) an impossible upload. Currently my internet access is screwed for about 5 hours every fortnight while I upload the new version. I don't see I could lose it for 5 times that long. It would also exceed my monthly quota in a single day. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Phil Holmes m...@philholmes.net writes: It seems to be fixing a problem we don't have. What would be the benefit? We have a problem reconciling potentially destabilizing work with the necessity to put out releases, in particular stable releases. That definitely _is_ a problem we have. I don't see Mike's particular proposal as currently tenable, either. I would also mention that, for this to work, there would need to be parallel documentation streams, too - otherwise users would read the docs for A, assume it's in B and rightly complain if it wasn't. This would entail 1) even _more_ confusion about which is the right doc set to read and 2) an impossible upload. Currently my internet access is screwed for about 5 hours every fortnight while I upload the new version. I don't see I could lose it for 5 times that long. It would also exceed my monthly quota in a single day. Well, this is one point we should likely be addressing at some point of time: we can probably cut down on platforms. Of course, that alone will not buy us enough leeway for a 5 times as much scheme. 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
- Original Message - From: David Kastrup d...@gnu.org 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. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Dec 10, 2013, at 5:07 PM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Mike Solomon m...@mikesolomon.org To: LilyPond Users lilypond-user@gnu.org Sent: Tuesday, December 10, 2013 1:23 PM Subject: survey on multiple development versions 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 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 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? Cheers, MS ___ It seems to be fixing a problem we don't have. What would be the benefit? Currently, LilyPond development is down from the level it was 2-3 years ago in terms of people proposing ambitious improvements (medieval music, footnotes, page breaking algorithms, etc.) with the exception of David’s work. I think that at least part of the reason for this is because of difficulties integrating large projects into the main branch. It might make more sense to think about improved ways of creating stable releases during a continuing development cycle. What you say above is a more general way to state the program. Generally, we need to figure out how can we have a robust continuous development cycle benefiting from multiple players while continuing to create stable releases. The survey I’m sending out is trying to gage one way that user participation may help in this - it is certainly not the only way. Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org 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. We will need to come to turns with how we will be trying to maintain a reasonable rate of stable releases without stifling forward-looking development more than is needed to not let the development diverge from the goal of stability terminally. This will certainly be a topic early in the 2.19 cycle which strictly speaking is already on. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup d...@gnu.org wrote: 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. This, to me, sounds like a plug-in solution is needed, at least for things that do not involve changing the C++ code (and maybe even then). The question is, if we're looking at releasing these binaries to reflect personal interest, how much are they actually going to be used? I have the feeling, though it may be unjustified, that while there may be a few people who would grab a binary with an experimental feature (self included, if it is one that I'm interested in and know something about), the use of the binaries may not be enough to justify the extra effort to make them available. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Dec 10, 2013, at 6:02 PM, David Kastrup d...@gnu.org wrote: Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org 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___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Tue, 10 Dec 2013 11:00:02 -0500 Carl Peterson carlopeter...@gmail.com wrote: This, to me, sounds like a plug-in solution is needed, at least for things that do not involve changing the C++ code (and maybe even then). I would hate the situation when I download a source for a piece of music and find that it requires a obscure plugin that was written for an old version of Lilypond ten years ago and never updated since then. The lifespan of music is much longer than the lifespan of Lilypond versions. We should try to keep Lilypond scores maintainable for years and maybe decades from now. Plugins can create problems. I'm not against plugins, it's just something to think about. -- Regards, Pavel Roskin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Am 10.12.2013 17:10, schrieb Mike Solomon: On Dec 10, 2013, at 6:02 PM, David Kastrup d...@gnu.org mailto:d...@gnu.org wrote: Phil Holmes m...@philholmes.net mailto:m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org mailto:d...@gnu.org 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Carl Peterson carlopeter...@gmail.com writes: On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup d...@gnu.org wrote: 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. This, to me, sounds like a plug-in solution is needed, at least for things that do not involve changing the C++ code (and maybe even then). That's very much my opinion. Recompilation is a very high threshold, and crossing it basically is platform-dependent. That means that we should strive to factor out as much as possible into Scheme. That is not, by itself, going to help. It is also necessary to factor the stuff into sensible units. If we take an example of one item that has been mentioned: footnotes. Footnotes consist of material that is anchored to locations on the page, and that is assembled into a footnote block of its own taking space on the page. Basically all of that is done interweaved into other C++ code. Which does not make a whole lot of sense since it is a reasonably independent task. If we are taking a look at why this happens, we can basically state as a goal to factor out the page builder. The page builder is part of the page breaking calculation, and as such a) its material have to be placed in special lists which are processed for page breaking b) its material contains items like springs that are not actually creatable or accessible in Scheme. So if we are going to use markup lists for building up a page from its elements, we need to have proper Scheme and likely also LilyPond representations of the items making up the material assembled into a page. Refactoring the page building into a stage where its basic operations can be done from Scheme/LilyPond would be a first big step towards being able to experiment with different schemes without recompilation. The next big step would be to create a modular structure where it is not necessary to replace the page builder for a feature like footnotes, but where you can plug in elements like footnotes by writing code for them and plugging this code into a single, extensible page builder with appropriate interfaces. Then we can have, without recompilation, tools that provide smarter footnotes, different layouts of them, margin notes and other stuff without interfering with other tools available for the page composition. The LaTeX core project is rather religiously keeping from ever touching the canonical TeX binary, and this has had quite a few ridiculous consequences. But it also enabled a large body of grown LaTeX/TeX code that can be used in parallel, due to some abstractions and interfaces and conventions that are far from convincing or enforceable in their technical implementation but which definitely do much more for being able to let multiple independent solutions be combined than the basic plain TeX format does. The question is, if we're looking at releasing these binaries to reflect personal interest, how much are they actually going to be used? I have the feeling, though it may be unjustified, that while there may be a few people who would grab a binary with an experimental feature (self included, if it is one that I'm interested in and know something about), the use of the binaries may not be enough to justify the extra effort to make them available. I share that concern. For that reason, I'd consider it important to spend a significant amount of effort not on thinking about how can expert programmers make LilyPond do something new rather than how can experienced users make LilyPond do something new. Or even something old. One part of the programmer/user distinction is that adding new functionality should _not_ require tampering with the existing installation, making it compile existing files differently when they don't access the added functionality. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Pavel Roskin pro...@gnu.org writes: On Tue, 10 Dec 2013 11:00:02 -0500 Carl Peterson carlopeter...@gmail.com wrote: This, to me, sounds like a plug-in solution is needed, at least for things that do not involve changing the C++ code (and maybe even then). I would hate the situation when I download a source for a piece of music and find that it requires a obscure plugin that was written for an old version of Lilypond ten years ago and never updated since then. The lifespan of music is much longer than the lifespan of Lilypond versions. We should try to keep Lilypond scores maintainable for years and maybe decades from now. Plugins can create problems. I'm not against plugins, it's just something to think about. In the LaTeX universe, packages survive rather long before becoming unusable. Binary plugins tend to last less long. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Dec 10, 2013, at 6:32 PM, David Kastrup d...@gnu.org wrote: Carl Peterson carlopeter...@gmail.com writes: On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup d...@gnu.org wrote: 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. This, to me, sounds like a plug-in solution is needed, at least for things that do not involve changing the C++ code (and maybe even then). That's very much my opinion. Recompilation is a very high threshold, and crossing it basically is platform-dependent. That means that we should strive to factor out as much as possible into Scheme. That is not, by itself, going to help. It is also necessary to factor the stuff into sensible units. If we take an example of one item that has been mentioned: footnotes. Footnotes consist of material that is anchored to locations on the page, and that is assembled into a footnote block of its own taking space on the page. Basically all of that is done interweaved into other C++ code. Which does not make a whole lot of sense since it is a reasonably independent task. If we are taking a look at why this happens, we can basically state as a goal to factor out the page builder. The page builder is part of the page breaking calculation, and as such a) its material have to be placed in special lists which are processed for page breaking b) its material contains items like springs that are not actually creatable or accessible in Scheme. So if we are going to use markup lists for building up a page from its elements, we need to have proper Scheme and likely also LilyPond representations of the items making up the material assembled into a page. Refactoring the page building into a stage where its basic operations can be done from Scheme/LilyPond would be a first big step towards being able to experiment with different schemes without recompilation. The next big step would be to create a modular structure where it is not necessary to replace the page builder for a feature like footnotes, but where you can plug in elements like footnotes by writing code for them and plugging this code into a single, extensible page builder with appropriate interfaces. Then we can have, without recompilation, tools that provide smarter footnotes, different layouts of them, margin notes and other stuff without interfering with other tools available for the page composition. I agree that this is a great candidate for refactoring. I think one way to frame the problem would be to imagine that someone wanted to take on this task, which is pretty ambitious and would likely require a lot of subtasks in extracting out the page breaker. Each of these subtests would require independent verification, and it is likely that the entire project could be done separately from the main branch. It would probably require extensive user testing to make sure that all the kinks were ironed out. Let’s say that I set up a version of LilyPond called modular-footnote-LilyPond in which I develop this modularity. How, if at all, can users test this before it makes it into the development version? Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Tue, Dec 10, 2013 at 5:10 PM, Mike Solomon m...@mikesolomon.org wrote: 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. i've been using lilypond since 1.4. and my workflow pertaining to stable/unstable releases has always been as follows: 0. use the latest stable release more or less as soon as it comes out 1. keep an eye on the CHANGES file for nice new features 2. if a feature is implemented that i feel is an improvement to the stable release (this happens quite often), then i upgrade to the unstable release 3. i stay on top of the unstable releases, also still keeping an eye on the CHANGES file 4. if i run into bugs (not very often anymore), i try to verify and report them 5. when the unstable branch moves to stable, so do i, and back to step 1. for instance: - the cool new features in 2.17 were \tuplet, tighter spacing, dot.notation.of.objects and \markLengthOn, several articulations feature; - 2.15 didn't have much exciting for me in it -- here i stuck with 2.14 until 2.16 came out. - 2.13 was a good development version with the instrument names fixed, q for repeating chords, dotted/dashed slurs, two-sided margins, white-out, segno bar-line, cresc text spanners, the partcombiner, cueDuringWithClef, beam collisions, ... [2.14. was a GOOD release] [etc. etc. for older development versions. i can't find the change files online for the older ones, but i remember there were lots of interesting new features in 2.9 and 2.7]. having multiple development versions with different feature sets in them would be, in my eyes, a large waste of disk-space on the lilypond server. also, as others have mentioned, it would be maintenance hell for helpful mailing list inhabitants. not to mention that you're less likely to catch weird interactions between new features, which do occur every now and then in the development versions... i think one reason for less forward movement is that a lot of really groundbreaking, spectacular stuff has been covered. a lot of the new features in this release are improvements on sufficiently functioning new features, making them better. and we all know that 80% of the time on a project is invested in the final 20% of the work. yes, contributing to the project is difficult and convoluted; not helped by some very unique people working on the project, but i wouldn't want to miss any of them working on my favourite piece of software. graham and david, just to name two very prominent ones, have had an amazing influence on lilypond and it wouldn't be where it is now without them. just my two euro-cents, sb -- Do not meddle in the affairs of trombonists, for they are subtle and quick to anger. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Tue, Dec 10, 2013 at 12:15 PM, Simon Bailey si...@bailey.at wrote: for instance: - the cool new features in 2.17 were \tuplet, tighter spacing, dot.notation.of.objects and \markLengthOn, several articulations feature; - 2.15 didn't have much exciting for me in it -- here i stuck with 2.14 until 2.16 came out. - 2.13 was a good development version with the instrument names fixed, q for repeating chords, dotted/dashed slurs, two-sided margins, white-out, segno bar-line, cresc text spanners, the partcombiner, cueDuringWithClef, beam collisions, ... [2.14. was a GOOD release] My personal upgrading experience is similar. I had a hiatus of a couple of years (at least) when I didn't use LilyPond (dating back to around 2.13.17 or so, IIRC), but recently, I was using 2.16.2 on my main computer until it became necessary to tweak things to fit a stylesheet I was working on, then I installed LilyDev on my iMac and eventually fired up my old Debian box. I used 2.17.26 or so for awhile, until I found out that the most recent releases incorporate MIDI panning, so right now I do my work on a hacked version of 2.17.95 for Mac (copying in modified versions of the part combiner Scheme file and the Feta font). Even though it doesn't take much to integrate those hacks now, I'm reluctant to do much upgrading unless there's a benefit to doing so. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Simon Bailey-5 wrote On Tue, Dec 10, 2013 at 5:10 PM, Mike Solomon lt; mike@ gt; wrote: 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. i've been using lilypond since 1.4. and my workflow pertaining to stable/unstable releases has always been as follows: 0. use the latest stable release more or less as soon as it comes out 1. keep an eye on the CHANGES file for nice new features 2. if a feature is implemented that i feel is an improvement to the stable release (this happens quite often), then i upgrade to the unstable release 3. i stay on top of the unstable releases, also still keeping an eye on the CHANGES file 4. if i run into bugs (not very often anymore), i try to verify and report them 5. when the unstable branch moves to stable, so do i, and back to step 1. For whatever it's worth, I've always used unstable builds from about 2 weeks after I started using LilyPond. I began with stable, but then quickly hopped on the unstables and have had zero issues with my scores. I love the bleeding edge, what can I say? :) I am a risk-taker! lol - composer | sound designer LilyPond Tutorials (for beginners) -- http://bit.ly/bcl-lilypond -- View this message in context: http://lilypond.1069038.n5.nabble.com/survey-on-multiple-development-versions-tp155496p155522.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Am 10.12.2013 18:30, schrieb SoundsFromSound: For whatever it's worth, I've always used unstable builds from about 2 weeks after I started using LilyPond. I began with stable, but then quickly hopped on the unstables and have had zero issues with my scores. I love the bleeding edge, what can I say?:) I am a risk-taker! lol Using unstable versions of a program like LilyPond is much less a risk than using a GUI tool that can crash and wipe away your current work. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Mike Solomon wrote If 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 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? I would likely be willing to help test such alternative versions, should that be the way things are organized. I think that if we were talking about just one such alternative version (or at most two?) instead of five, then this would be a lot simpler and more feasible from a user's standpoint. But maybe that would not be enough to achieve what you're trying to accomplish. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/survey-on-multiple-development-versions-tp155496p155529.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Working on many parallel versions seems in some ways seductive, the dream of improving many things all at once, but I agree keeping to a single release cycle is definitely less prone to creating all sorts of unintended problems from conflicting development to documentation degradation. This program is at point where many many things work right and very well. The LilyPond wishlist of functionality might be incomplete, but it will get there or at least it should. We have some highly useful people keeping things in order, especially David K. In any event if a roadmap of future effort was released it might allow people the ability to give there input in a more structured way. Sometimes it feels like certain things are accomplished as people happen to get them. or as people are pushed to get to them. Any my point is the progress seems nebulous at times, maybe it isn't. in terms of usage I have been running usually the latest release and jump to the next current when I do more LilyPond work which makes my updating of the program sporadic and not in line with the release dates. This is one of the few programs that does not cause any fears about upgrading to the edge. So I would suspect there are many other users that upgrade to a unstable release for that bright shiny new feature or curiosity, but it might not be the case there would be enough to have any sort of rigorous base of use to support multiple development versions. As for plugins, that notion is a dismal sop. As people have pointed out plugins are hard to maintain long term, and to me at least when i need such things it really spoke loudly about the basic inadequacy of the program being used. At least in my experience it has been very rare that something could not be achieved without resort to simply waiting it out for the development to catch up to demand, basically because our user base has an incredible knack for making work arounds with the existing functionality. And with each release it seems the need for these work arounds goes down. So the level of thrashing things out is good to see, keep at it, but let us not get into a situation where we are forking ourselves to death and ruining the steak. Shane On Tue, Dec 10, 2013 at 12:49 PM, Urs Liska u...@openlilylib.org wrote: Am 10.12.2013 18:30, schrieb SoundsFromSound: For whatever it's worth, I've always used unstable builds from about 2 weeks after I started using LilyPond. I began with stable, but then quickly hopped on the unstables and have had zero issues with my scores. I love the bleeding edge, what can I say?:) I am a risk-taker! lol Using unstable versions of a program like LilyPond is much less a risk than using a GUI tool that can crash and wipe away your current work. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
I wonder if this is coming across more confusing than it has to be. You're talking about branching a feature branch from the mainline (probably the development branch: 2.17.24, 2.17.25, etc) and merging from it (as the mainline changes), while the feature branch is improved, until the feature branch is stable enough to merge it back into the mainline. If the feature branch isn't yet stable enough to make a big release like 2.18, then no problem, keep it separate and continue to merge from the mainline until it's ready, and then merge it back to the mainline. If new changes are made to the mainline that are inherently incompatible with the feature branch, then switch approaches by considering the feature branch as a temporary fork. Instead of merging from the mainline, instead merge from the various smaller feature branches that are also merged into the mainline, that aren't incompatible with the feature branch. In other words, if someone wants to make a change to the mainline, they do it in their own branch - and then when it comes time to contribute it back to the mainline, the fork branch accepts it as well. If there isn't a way to set up this process easily, you could probably do this alternatively by doing selective merges from the mainline into the feature branch. From the perspective of the mainline, it doesn't care because it's not being negatively affected, and it doesn't limit its release schedule. It doesn't care what is being pulled from it, it only cares what is being pushed to it. From the perspective of the fork branch, it has the time to get stable before it gets re-integrated back into the mainline. From the perspective of the user, it isn't as complicated as them having A B and C all seeming equally valid and confusing. There's the release (2.18, 2.19, etc), the development line, and if they want one of these experimental branches they have to use one of the forked releases - I would expect that these types of users would be pretty savvy about keeping track of the differences, and perhaps able to build binaries themselves. Curt On Dec 10, 2013, at 5:23 AM, Mike Solomon m...@mikesolomon.org 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 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 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? Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On 12/10/2013 06:41 AM, Carl Peterson wrote: On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon m...@mikesolomon.org mailto:m...@mikesolomon.org 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 lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Urs Liska u...@openlilylib.org writes:
Am 10.12.2013 18:30, schrieb SoundsFromSound:
For whatever it's worth, I've always used unstable builds from about 2 weeks
after I started using LilyPond. I began with stable, but then quickly hopped
on the unstables and have had zero issues with my scores.
I love the bleeding edge, what can I say?:) I am a risk-taker! lol
Using unstable versions of a program like LilyPond is much less a risk
than using a GUI tool that can crash and wipe away your current work.
There was a time when people lost work using LaTeX on MSDOS in spite of
it being a batch application.
Here was the deal: the syntax to include separately includable files in
LaTeX is
\include{filename}
now sometimes people wrote
\include{filename.tex}
by mistake but that meant that auxiliary information about the file was
written to filename.tex.aux which MSDOS abbreviated to filename.tex.
Very ugly. Very unexpected. At some point of time, TeX engines were
changed in order to refuse writing a file under comparable
circumstances.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Mike Solomon m...@mikesolomon.org writes: On Dec 10, 2013, at 6:32 PM, David Kastrup d...@gnu.org wrote: Refactoring the page building into a stage where its basic operations can be done from Scheme/LilyPond would be a first big step towards being able to experiment with different schemes without recompilation. The next big step would be to create a modular structure where it is not necessary to replace the page builder for a feature like footnotes, but where you can plug in elements like footnotes by writing code for them and plugging this code into a single, extensible page builder with appropriate interfaces. Then we can have, without recompilation, tools that provide smarter footnotes, different layouts of them, margin notes and other stuff without interfering with other tools available for the page composition. I agree that this is a great candidate for refactoring. I think one way to frame the problem would be to imagine that someone wanted to take on this task, which is pretty ambitious and would likely require a lot of subtasks in extracting out the page breaker. Each of these subtests would require independent verification, and it is likely that the entire project could be done separately from the main branch. It would probably require extensive user testing to make sure that all the kinks were ironed out. Let’s say that I set up a version of LilyPond called modular-footnote-LilyPond in which I develop this modularity. How, if at all, can users test this before it makes it into the development version? Uh, not really? That was sort of my point. Refactoring into extensible form is a prerequisite to development of features that are not tightly tied into a particular binary, requiring its recompilation. But there won't be significant resistance to that kind of work while we are in the unstable phase of a development version. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
On Dec 10, 2013, at 9:08 PM, Colin Campbell c...@shaw.ca wrote: On 12/10/2013 06:41 AM, Carl Peterson wrote: On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon m...@mikesolomon.org 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 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 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? 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 Thanks for all the responses - they are very useful. It sounds like this is a bad idea. Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: survey on multiple development versions
Am 10.12.2013 19:46, schrieb David Kastrup:
Urs Liska u...@openlilylib.org writes:
Am 10.12.2013 18:30, schrieb SoundsFromSound:
For whatever it's worth, I've always used unstable builds from about 2 weeks
after I started using LilyPond. I began with stable, but then quickly hopped
on the unstables and have had zero issues with my scores.
I love the bleeding edge, what can I say?:) I am a risk-taker! lol
Using unstable versions of a program like LilyPond is much less a risk
than using a GUI tool that can crash and wipe away your current work.
There was a time when people lost work using LaTeX on MSDOS in spite of
it being a batch application.
Here was the deal: the syntax to include separately includable files in
LaTeX is
\include{filename}
now sometimes people wrote
\include{filename.tex}
by mistake but that meant that auxiliary information about the file was
written to filename.tex.aux which MSDOS abbreviated to filename.tex.
Very ugly. Very unexpected. At some point of time, TeX engines were
changed in order to refuse writing a file under comparable
circumstances.
Interesting case ...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
