Re: [GLISS] - alternative viewpoint

[Marc Hohl]

[sorry, forgot to hit "Reply to all"]
Am 20.09.2012 19:02, schrieb David Kastrup:
> Marc Hohl <address@hidden> writes:
>
> > [...]
> The problem is not people not interested in this kind of
> discussions/proposals.  The problem is people who stop being interested
> in an oh so important problem the moment one tries offering different,
> more feasible solutions than what they were thinking of.
>
> If the problem is not important enough to give feasible approaches at a
> solution serious consideration (which most certainly would include
> explaining in which way they appear inferior to the less feasible
> approaches), then it is hard to consider it important enough to bother
> with the infeasible approaches.
That's true.
> > I can only speak for myself, but the main "problem" is that most of
> > the time I can spend for working on LilyPond is put into the actual
> > patches; the reviewing process is handled rather shabbily, I confess.
> With regard to reviewing user interface additions, it may indeed be the
> case that other developers don't care much since they could get along
> fine previously, trust they'll get along fine in future, and maybe trust
> other developers not to do all too much damage.
>
> But we don't have users involved either.  And those are actually the
> ones for which such additions are made.  Involving them instead in a
> planning stage largely disconnected from actual developments is a poor
> substitute.
+1
> [...]
> > Do you propose that the user base should get more information
> > about development work?
> Yes.
>
> [...]
> Within specific sub-areas like tablature support, this apparently works
> better than when LilyPond as a whole is concerned.
The strategy to split the development process into sub-areas
and announce them on -user might be a good plan; this means that
someone has to provide a reasonable "interface" so that users
can be easily informed about topic x.
This is probably easy when topic x is about extending some features
or defining new features lilypond should have, but in other cases
you'll need a way to allow users to test patches, and that's more
difficult, I think (except there is a way to extend the automatic patch
test mechanism so that users can download special precompiled
versions of lilypond including a certain patch set and test it thoroughly
before this feature becomes official).
> "Let's write a subsystem/package for this" is just much more manageable
> than "let's change LilyPond as a whole".
>
> Obviously, we should strive to change LilyPond as a whole in order to
> make it easier to delegate problems to the subsystem/package level.
> That allows for much more parallelized processing.
+1

Do you already have a strategy how to split the whole system
into subsystems?
Do you think of extending the way the work on lilypond is done at present
(i.e. the patch revision system and the code guidelines stay mostly
unchanged) or rather to allow for something like the macro packages
in LaTeX, where anyone can roll his own package, writes a documentation
for it and may upload it on some server?

Regards,

Marc
>