Tracker 1686 - Process question - separate Tracker Issues or handle patches as part of T1686?

[Ian Hulin]

(For especial attention of Graham, Bug Squad, David, Bertrand and
\markup rewrite hackers)
Hi all,

I've been hacking away in the Guile V2 migration cave working on
Tracker 1686.  This is to provide LilyPond with the ability to produce
compiled Scheme files which we can load and use and eventually
make-install into a known area as part of installing the binary kit.

This is so we can avoid using Guile V2 auto-compile which is fine and
dandy in its way but is a complete black box and one for which there
is no control over where the compiled go or what they are called.
Obviously useless in a project like LilyPond where you need to know
what the files are called and where they are so you can move them
during installation to where you need them to be.

During the course of hacking on my Guile V2 laptop system the
following "collateral damage" issues have cropped up in order to allow
Lily on a Guile V2 system to get through phase one of initialization
(that's the bit where we run up lily.scm from the image and load all
the other scm/*.scm files to build the (lily) guile module.  The base
change for 1686 would require changes to lily/main.cc and
scm/lily.scm, but in order for these to fly I need to do the following:
o Move the safe-objects guile data definition and define-safe-public
  macro into a new (scm⁠ ⁠safe⁠-⁠⁠utility⁠-⁠⁠defs) module
   - add (use-modules (scm safe-utility-defs)) to lily.scm
   - add (use-modules (scm safe-utility-defs)) to other scm/*.scm
     files⁠ ⁠using the define-safe-public macro.
o Move all the markup macros and markup definition procedures to a new
  (scm markup-facility-defs) module (this is the artist formerly known
  markup-macros.scm and the remaining code in markup.scm)
   - add (use-modules (scm markup-facility-defs)) to all the scheme
     files that use the define-markup-command,
     (especially define⁠-⁠markup⁠-⁠⁠commands.scm).
   - reorder declarations in define-markup-commands.scm so they don't
     forward-reference commands not yet declared (#line is the real
     killer, as it is implicitly used in the
     compile-markup-expression and compile-all-markup-expressions
     procedures).
   - change the validation for lookup-markup-command-aux to look
     explicitly in the (lily) module for markup commands already
     defined rather than in the current module as the Guile
     compile-file changes (current-module) to an anonymous module and
     this breaks our code. (Yes, I know it's a Guile bug but life is
     too short not to work around it while I beat up the Guile
     developers and convince them it really is a problem).

OK, here's the question, what's better for our
development/bug-tracking/project management process - add a new
tracker for each of the two modules and mark them as blocking 1686, or
put up patch-sets for each of these as part of Issue 1686, and then
when they've been reviewed, counted down and pushed, put up the final
changes to lily.scm and main.cc, and when this one is reviewed,
counted down and pushed, then we can verify the issue.

By the way, the criteria for verifying all of these patches is that
they do no harm when running the LilyPond regression tests using Guile
1.8.

Cheers,

Ian Hulin