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 don't know whether a translator comes before or after an engraver. I don't know whether grobs create engravers, or are created by them, or whether they live primarily in scheme or c++ or whether these question make any sense whatsoever. I only discovered that engravers do pdf and performers do midi a few days ago while skimming emails on this mailing list. With the possible exception of the (human language) translators, I know less about the lilypond internals that anybody else with git push ability. But I *do* know that computers are deterministic. If we consistently get output that we don't want -- and a segfault is definitely "output that we don't want" -- then there is some combination of bits in some place(s) in memory (or in CPU registers) which are the opposite of what they think they should be. Period. Maybe in 20 years when we're all using quantum computers that won't be true, but right now, it all comes down to 0s and 1s. That's basic electrical engineering. As a matter of software engineering, I know that any programming problem can be broken into a series of smaller problems. Does something look complicated? Break it into steps. Is the first step complicated? Break it into steps. Is the first step of the first step too complicated? Break into steps. We can keep on going until we reach the level of NAND gates. Now, these days, using common chips, there's absolutely no reason to go that far -- breaking things down to arithmetic operations and memory locations will be enough for any problem. Is lilypond a complicated beast? Sure. 69k lines of c++, 29k lines of scheme, 19k lines of python, etc. But as long as I'm alive, I can learn more about it. Archimedes was reputed to have said "give me a lever long enough and a fulcrum on which to place it, and I shall move the world". I'm saying "give me the source code, the ability to compile it, the ability to add printf()s, and enough time, and I can fix all the critical issues." 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. - Graham Percival _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel