Re: 2.14 release, or GOP now (part 2)
On Mon, Nov 29, 2010 at 06:37:08AM -0700, Carl Sorensen wrote: What about option 0 -- try to coordinate the resources we currently have available on the critical issues? I would like that. I'm a bit surprised to see so many people talking about branching a stable/2.14 -- I don't think that would solve anything. I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. I'm not sure if this is feasible or not, but I regularly check the critical issues to see if I can help resolve them. Here's a rundown of my typical check. -snip- To summarize it: you expect Joe to fix 2 issues, Neil to fix 3, and John to fix 1. However, according to the issue tracker, John and Neil have both started 1 issue. Given his expertise and the number of other open issues, I agree that working on the spacing issues would not be very efficient. But I disagree with ignore critical issues entirely. Right now, for this specific set of critical issues, it appears to me that those who have the knowledge and skills to solve the issues is working on them. Anybody else would need to climb a big hill to get ready to solve them. I do not disagree with this. However, my conclusion is not let's frolic and party in the valley; my conclusion is let's start climbing -- in particular, let's start climbing *together*. To use a sports analogy, our current teamwork is like playing doubles tennis. Person A works on stuff x. Person B works on stuff y. The project as a whole benefits from this specialization. However, at the moment we have an overabundance of stuff x. Should Mr. B, C, D, E, and F just sit around waiting for Mr. A to deal with all the stuff x ? I don't think so. Instead of doubles tennis, let's play volleyball. Let's all (or at least, everybody other than Joe+Neil+John) works together on an issue. Instead of one person hitting the ball back, let's have multiple people stop the ball, set it up, and then send it back. Will it take us longer than if Neil did it himself? maybe. But is Neil such a genius that he can solve all the critical issues before we can solve one? With absolutely no disrespect to him, I don't think so. I think that if you, me, Patrick, Valentin, Keith, Mark, Marc, Trevor, etc., all work together on just ONE critical issue, we can get it fixed before Neil finishes all the other issues. Let's examine 1336 in detail, since I happen to be more familiar with it. - Valentin created a good Tiny example. - Patrick created a backtrace. That's useful for me, since I don't know how to create them. - I started to investigate it in my stupid manner. I think that I've isolated the part of code that's segfaulting. It has something to do with X-offset. I've now posted patch so that anybody can reproduce and check my results. - Neil suggested -- again, no disrespect to him, but it was a *suggestion*, not *knowledge* -- that the cause was something about cloning a MultiMeasureRest. What's the next step in this story? Well, I'd like some evidence that MultiMeasureRest is actually the problem. - a brief look at the source suggests that MultiMeasureRest isn't in one of the lily/*.cc files; it's actually in scm/. I have no clue which scheme file handles cloning -- or even what that word means in the context of lilypond internals -- but that's no reason for me to give up. There will be some .cc file that I can add a printf() to, or some scheme file that I can add a (display...) to, which will print out a suspicious piece of text when I compile bad.ly, but which will print out no suspcious text when I compile good.ly. - Somebody who knows about scheme -- Mark, Valentin, Trevor? -- could help a lot in this investigation. Or some combination thereof. - Maybe Trevor only has enough knowledge+time this morning such that he could identify that the cloning happens on line 123 of scm/define-grob-properties.scm. That's not a failure, that's not useless -- that piece of knowledge is vital for the next step! - Then maybe in the afternoon, Valentin can afford to spend 30 minutes inserting (display...) into random places near line 123, and discovers that add (display (my (bounds)) to line 138 displays the suspicious/non-suspicious text. Great! - Then at midnight Europe time but mid-afternoon Canadian-time, Mark the scheme guru looks at the output, and realizes that the whole thing could be fixed by adding (if (!= (my (bounds) 0) to line 872 of scm/cloning-a-grob.scm. Or maybe there's still more steps required in this story. Maybe he spends two hours poking around, and doesn't see any obvious next step. Sometimes that's what happens. But he writes about what he tried, so mid-morning European time I read about his attemps, and think of other things to try. Look, I am not scared of lilypond. I know almost nothing about our internals. I
Re: 2.14 release, or GOP now (part 2)
On Wed, Dec 1, 2010 at 9:46 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Graham Percival wrote Tuesday, November 30, 2010 8:04 AM I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. It wouldn't, but that wasn't the point of the suggestion. There's a history of new code not working quite right due to bugs, oversights, etc that only come to light a few weeks later. That's why the release plan calls for having a release candidate for two weeks, with no critical issues reported against it, before making a stable release. That release candidate would of course be made from a separate branch, with only translation patches being applied to that branch. I'll wait another day for comments in case anybody missed it due to the savannah list downtime, but I despite my objection, I'll branch stable/2.14 in the next few days unless anybody speaks heavily against it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Wed, Dec 1, 2010 at 11:16 AM, Graham Percival gra...@percival-music.ca wrote: I'll wait another day for comments in case anybody missed it due to the savannah list downtime, but I despite my objection, I'll branch stable/2.14 in the next few days unless anybody speaks heavily against it. It might be better to wait just a bit more, Neil (possibly Reinhold) and I still have outstanding patches (by which I mean that these patches are awesome, of course :) I'm not sure your usual I'll do thisthat in 48 hours unless someone objects before then is the right approach here: you might want to consider announcing I'm planning to do thisthat, do I have your green light? and then wait for all major contributors (i.e. not me) to catch up. (Just a thought.) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On 11/30/10 1:04 AM, Graham Percival gra...@percival-music.ca wrote: On Mon, Nov 29, 2010 at 06:37:08AM -0700, Carl Sorensen wrote: What about option 0 -- try to coordinate the resources we currently have available on the critical issues? I would like that. I'm a bit surprised to see so many people talking about branching a stable/2.14 -- I don't think that would solve anything. I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. Instead of doubles tennis, let's play volleyball. Let's all (or at least, everybody other than Joe+Neil+John) works together on an issue. Instead of one person hitting the ball back, let's have multiple people stop the ball, set it up, and then send it back. OK, I'm up for a volleyball game. However, I'm not sufficiently motivated to do it all by myself if lots of other people are only working on new features or discussing policy changes. If they're having fun, then I want to have fun too. But if there's a solid core of people doing the hard work of trying to fix critical issues, then I will absolutely be part of that group. Me too. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Mon, Nov 29, 2010 at 8:33 AM, Graham Percival gra...@percival-music.ca wrote: 2) release 2.14 ASAP with no critical flaws, but with some kind of code freeze. Many software projects implement a freeze before a release -- when the project is frozen, this means that no changes are allowed, unless they have a very good reason why they absolutely must be changed before the next release. With git, there's no technical reason why we might want to freeze anything (I could just branch a stable/2.14, and just cherry-pick individual commits to apply to this branch). However, there are social reasons for a freeze. We (implicitly) have a freeze on policy decisions, to avoid spending time on those instead of release-critical work. We could add a freeze on patches and code, to avoid spending time on those instead of release-critical work. I think branching is the right thing to do here. This what the Fedora guys have been doing for their last couple of releases: as soon as they reach alpha stage, they branch off the new version and continue development on master, with the branched branch only getting backports of bugfixes. Yes, I hear you saying that we probably don't have the resources for such things. I'd have agreed with you three years ago, but I'm not so sure today. If anything, we probably should have branched 2.14 off much earlier (please note however that as far as I can see, of all the critical bugs we have now, none has been introduced in the past two or three months). I do not like this idea either. This is a volunteer project; telling contributors that we will (for example) not discuss any changes to tabulature code is not going to encourage those volunteers to stick around. Wow, I didn't even knew tabulature was a proper word :) 3) continue development as we do now. We have a freeze on policy decisions, but not code. Expected release is Feb - March 2011. I am personally fed up with critical bugs, so I would spend a bit more time helping new contributors, but I would not raise any policy questions. We make no particular attempt to focus development on release-critical issues. Are you still planning to work on 1336? I am aware that there is some dissatisfaction with the current state of affairs. I am neutral on this point. I'd rephrase that as I like to think of me as being neutral on this point ;-) What do you think? This is not a vote, but I would like to hear from people. I am hoping that we can find a reasonable amount of consensus. As far as I'm concerned, option #2, certainly. I keep thinking (me being fluffy and all) that a Xmas-New Year release would be nice, a bit like Han-Wen did with 2.12 (only more deliberately planned ahead). Cheers, Valentin. (PS. Perhaps now would be as good a time as any to publicly state that I'm leaving the project by the end of the year, partly due to aforementioned dissatisfactions. So whatever I might have to say until then can, and likely will, be safely disregarded.) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
Graham Percival wrote Monday, November 29, 2010 7:33 AM With that in mind, I'm reopening the same question as the 24 Oct email. 2) release 2.14 ASAP with no critical flaws, but with some kind of code freeze. I prefer a variant on this. Branch 2.14 now and apply only patches to critical problems to it. That will at least prevent new bugs arising from new code. Continue to allow development in 2.15 unrestrained. Do not start GOP or GLISS until 2011. That allows time over the holiday period for critical bugs to receive attention, permitting (hopefully) a release of 2.14.0 early in 2011. Announce (to development) a target date for releasing 2.14.0, say 15 Jan 2011, to encourage work on bugs, translations, docs, etc over this period. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On 11/29/10 12:33 AM, Graham Percival gra...@percival-music.ca wrote: What do you think? This is not a vote, but I would like to hear from people. I am hoping that we can find a reasonable amount of consensus. What about option 0 -- try to coordinate the resources we currently have available on the critical issues? I'm not sure if this is feasible or not, but I regularly check the critical issues to see if I can help resolve them. Here's a rundown of my typical check. Hmm, let me go look at the critical issues. 1252 -- music overflows page. It's a spacing issue, and Joe is working on it. Joe knows all about the spacing, so it makes sense to leave it to him. 1290 -- Skyline compaction goes overboard. It's a spacing issue. It's had some good work on it to help identify the specific issue, and Joe has raised a possible solution, but not the code for it. I guess leaving it to Joe is the right thing. 1336 -- Graham has identified the pointer that causes the segfault. Neil has identified the reason the pointer is null. Since Neil understands the internals better than anybody else, as far as I can tell, I'd guess there will be a fix coming soon from Neil. 1427 -- Neil is actively working on this one, and appears to be close. A patch is posted, but AFAICS, on hold due to something that should work but doesn't. Again, Neil seems to be on it. 1428 -- Split off of 1427, it's the problem that is holding up the regtest for 1427. Neil's on it. 1363 -- Build system. It's so icky that it should be handled only by experts. We have two, John and Graham. They're working on it. So we've got 6 critical issues. All of the issues are being worked on by those who are experts in the area. I'm not an expert in any of those areas; it would take me a long time to get up to speed in any of them. How can I help? I don't see any way. So I'll go work on some new features such as tablature stuff requested by users. Is there any way that I could be used to help out the situation? For example, can Joe point me in the direction of where I could look to try a solution for 1290 (more specific than the current comment, e.g. look at lines xxx to yyy of file lily/frobozz.cc or look at moving the padding addition from Staff_engraver::handle_widgets to Score_engraver::break_the_code)? Or is there something else that Joe or Neil is working on that I can take over, so they have more time available for the critical issues? Right now, for this specific set of critical issues, it appears to me that those who have the knowledge and skills to solve the issues is working on them. Anybody else would need to climb a big hill to get ready to solve them. If any of you can think of a way I can be of use in resolving these issues. please let me know. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Sun, Nov 28, 2010 at 11:33 PM, Graham Percival gra...@percival-music.ca wrote: 2) release 2.14 ASAP with no critical flaws, but with some kind of code freeze. Many software projects implement a freeze before a release -- when the project is frozen, this means that no changes are allowed, unless they have a very good reason why they absolutely must be changed before the next release. With git, there's no technical reason why we might want to freeze anything (I could just branch a stable/2.14, and just cherry-pick individual commits to apply to this branch). However, there are social reasons for a freeze. We (implicitly) have a freeze on policy decisions, to avoid spending time on those instead of release-critical work. We could add a freeze on patches and code, to avoid spending time on those instead of release-critical work. I like the idea of branching master to stable/2.14 and cherry-picking fixes for critical issues (and compile/build fixes for Guile 1.9, etc). Merging translations work from lilypond/translation to stable/2.14 would be just as easy. This would allow work in master to proceed uninterrupted. I also think it would be useful to have two code freezes on stable/2.14: one for code/docs, and one for translations (right before the release). Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On 11/29/10 4:49 AM, Valentin Villenave valen...@villenave.net wrote: (PS. Perhaps now would be as good a time as any to publicly state that I'm leaving the project by the end of the year, partly due to aforementioned dissatisfactions. So whatever I might have to say until then can, and likely will, be safely disregarded.) I'm sorry to hear that you are leaving the project. Your contributions will be missed. Sincerely, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
On Mon, Nov 29, 2010 at 9:29 AM, Valentin Villenave valen...@villenave.net wrote: On Mon, Nov 29, 2010 at 6:22 PM, Patrick McCarty pnor...@gmail.com wrote: I also think it would be useful to have two code freezes on stable/2.14: one for code/docs, and one for translations (right before the release). (Of course it depends on how much new work is done after stable/2.14 is branched off, but) don't you think translators would be better off keeping in sync with the *stable* branch until the release? This way we might have a chance that most languages are in the same state when the release happens. Yeah, this situation is tricky. One idea would be to branch stable/2.14 *only* after the (English) documentation is in a state good enough for 2.14 (a topic for another thread), and then we branch stable/2.14, and translation work commences for documentation on stable/2.14. I think that would work... :) Once stable is released, then lilypond/translations can be rebased onto master, until the next branching stage. Would probably be easier to merge it, since most (if not all) translation work, before the 2.14 release, would be based off stable/2.14. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
