[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLISS] - alternative viewpoint
From: |
Marc Hohl |
Subject: |
Re: [GLISS] - alternative viewpoint |
Date: |
Fri, 21 Sep 2012 10:27:50 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 |
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
- Re: allowing \f and \F, (continued)
- Re: allowing \f and \F, Graham Percival, 2012/09/22
- Re: allowing \f and \F, Sue Daniels, 2012/09/24
- Re: allowing \f and \F, Graham Percival, 2012/09/23
- Re: allowing \f and \F, Janek Warchoł, 2012/09/24
- Re: allowing \f and \F, David Kastrup, 2012/09/24
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/20
- Re: [GLISS] - alternative viewpoint, Marc Hohl, 2012/09/20
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/20
- Re: [GLISS] - alternative viewpoint, Marc Hohl, 2012/09/20
- Message not available
- Re: [GLISS] - alternative viewpoint, Thomas Morley, 2012/09/20
- Re: [GLISS] - alternative viewpoint,
Marc Hohl <=
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/21
- Re: [GLISS] - alternative viewpoint, Marc Hohl, 2012/09/22
- Re: [GLISS] - alternative viewpoint, Janek Warchoł, 2012/09/22
- Re: [GLISS] - alternative viewpoint, Graham Percival, 2012/09/23
- Re: [GLISS] - alternative viewpoint, Marc Hohl, 2012/09/23
- Re: [GLISS] - alternative viewpoint, Sue Daniels, 2012/09/24
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/23
- Re: [GLISS] - alternative viewpoint, James, 2012/09/23
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/23
- Re: [GLISS] - alternative viewpoint, Jan Nieuwenhuizen, 2012/09/24