Re: 2.14 release, or GOP now (part 2)

[Graham Percival]

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