Re: [GLISS] - alternative viewpoint

[Marc Hohl]

Am 21.09.2012 00:31, schrieb Thomas Morley:
> [...]
>   Hi David, Marc,
>
>   speaking only for me: I'm terrible sorry that I currently can't give
>   you the feedback you desire. Since my injury, I wasn't able to
>   concentrate on any more involved project or to finish any larger one.
>   Also, I let Marc alone with the bar-line-code, we started to tackle together.
>
>   Marc, please accept my apologies.
No problem for me at all – I had some bad feelings that I grabbed
your ideas and modified it to my needs without some discussion
with you. I hope that's ok for you.
>   So I mostly limited my activities to answer questions on the user-list, FWIW.
And you do a great job there, BTW!
>   But perhaps you may accept some summarizing thoughts about involving
>   users in the development-process. (Most of them already mentioned)
>   Or better: why it doesn't work, currently.
>
>   Thinking of an average user, subscribing the user-list only:
>   (1)
>   He's often not informed that sth is planned/discussed/in-work.
Sure.
>   (2)
>   If he's informed and looks at the code on Rietveld, he doesn't know
>   what to do with it, because very often there's no
>   example/regtest/snippet _how_ to use the new
>   syntax/feature/code/whatever.
>   Ok, Rietveld is not the place to put in such additional, illustrating
>   examples, etc.
>   But I think you get my point.
Ok. But this means that the programmer who worked on the patch should
do the documentation part at the same time, so that any one will understand
what the patch is all about.

I second this if it is about writing inline comments in the source code.
I did this with by current bar line patch, because more often than not
I have to try to understand some parts of a programm *I* had written
myself some months ago.

But for the bar line patch: I would be glad if someone else wanted to
write some paragraphs about the new interface, but I think this task
will be mine anyway ;-) But I don't want to tackle around with the 
documentation
*yet* while it is not sure that my patch gets accepted and the new 
interface is
considered a good idea by most of the developers.
So while in an ideal world every programmer enhances the documentation
on the fly, I don't think it would be a good idea to *force* them to do so.

So, you either have to figure out for yourself how the patch is supposed 
to work
(as a user), or there is a possibility to include some small test files 
that show
the functionality. I think *every* developer has some 'quicktest.ly' files
around that he uses for testing, and they would serve as a testbed for
anyone trying to get a grip on the new stuff.
>   (3)
>   Thinking of more involved tasks like testing a patch (and managing the
>   tools needed to do so), I assume this is not a task an average-user is
>   expected to manage, with the current system.
>
>   At least I had some larger problems installing LilyDev (I wasn't able
>   to install the required fontforge-version, I had to ask for help)
>   Also, learning how to deal with the new world of git-commands is
> time-consuming.
>   etc etc
So I repeat my proposal: in this case we need *precompiled* test versions.
I don't know if that is feasible in terms of disk space and work load 
(it had to
be done on GUB), but at least patches with a major impact on lilypond's
usability/syntax/whatever could then easily be tested by a broader user
community if this just means to download and install an executable
and recompile your current scores with it.

Regards,

Marc