Re: ’Pond Jobs & Their Descriptions

[Urs Liska]

Am Mittwoch, den 05.02.2020, 22:26 -0500 schrieb Kieren MacMillan:
> Hi Graham,
> 
> > Oh, that would definitely be a good idea!
> 
> Okay, then! I’ll start with your suggestion to [paraphrasing:]
> "summarize the jobs described in the CG", and prepare a skeleton
> document where each entry is like that one.
> 
> > (I'm not quite certain about the "Receives From" and "Passes To"
> > lines, as I think that implies a more formalized process than
> > LilyPond has
> 
> Those would be more for understanding the flow of the process, and
> figuring out where combinations/elisions can happen (e.g., someone
> might have sufficient skill and interest to be both Patch Submitter
> and Patch Formatter), and where automation can help (e.g., code
> formatting LOL).

If I'm not mistaken such a list wouldn't/shouldn't imply that
separating jobs relies on assigning one job per person (wow, why do my
fingers insist typing "mob" instead of "job" this morning???)

It *might* be misleading someone to think your effort would go in that
direction of a strictly formalized working environment, but a) we don't
have so many people for so many jobs and b) of course many people can
do much more than one task of such a list.
But such a detailed "job description" would probably be very helpful
when thinking about a possible improvement/solution/patch: What do I
want, what is needed to achieve it, which parts can I do myself, for
what exactly do I need assistance?

Urs

> 
> Best,
> Kieren.
> 
> 
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 
> 

PATCHES - Countdown for February 6th

[pkx166h]

Hello,

Here is the current patch countdown list. The next countdown will be on
February 8th.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/


***


 Push:

5732 Use unique_ptr in layout code - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5732
http://codereview.appspot.com/573500043

5731 Remove outdated comment in scm-hash.hh - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5731
http://codereview.appspot.com/547570043

5730 Cast to Real in C++ style throughout - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5730
http://codereview.appspot.com/547560044

5729 Fix SyntaxWarning's - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5729
http://codereview.appspot.com/559440043

5728 GUILE v2: set postscript output port to Latin1 - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5728
http://codereview.appspot.com/563400065

5727 Make all int -> Real casts explicit - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5727
http://codereview.appspot.com/563460043

5726 Remove check for rational bugfix. - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5726
http://codereview.appspot.com/555230043

5724 Some cleanups for Python code - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5724
http://codereview.appspot.com/551430044

5723 Pedal_type_info maintenance - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5723
http://codereview.appspot.com/557270049

5722 lilypond-book: Remove custom package loading - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5722
http://codereview.appspot.com/553490051

5721 lilypond-book: Rewrite processing of snippets - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5721
http://codereview.appspot.com/555220043

5720 Add enabling extension definitions for `-std=c++11` option - 
Masamichi Hosoda

https://sourceforge.net/p/testlilyissues/issues/5720
http://codereview.appspot.com/579270051

5716 Make Pitch::to_string() more robust - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5716
http://codereview.appspot.com/581580043

5715 Use define-syntax for define-session[-public] - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5715
http://codereview.appspot.com/553480044

5714 Document 2 functions in markup-macros.scm - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5714
http://codereview.appspot.com/581570043

5706 Doc: Correct and extend infos about LilyDev setup - xmichael-k
https://sourceforge.net/p/testlilyissues/issues/5706
http://codereview.appspot.com/561360043

5703 Run scripts/auxiliar/fixcc.py - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5703
http://codereview.appspot.com/549480043

5674 document and test slur score debugging - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5674
http://codereview.appspot.com/555160043



 Countdown:

5740 Add \post to defer context actions to end of time step - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5740
http://codereview.appspot.com/581600043

5736 Fix input/regression/context-find-parent.ly - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5736
http://codereview.appspot.com/559460043

5735 Rewrite define-session and define-session-public macros - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5735
http://codereview.appspot.com/549510043

5734 Fix convert-ly with Python 3 - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5734
http://codereview.appspot.com/555260044

5733 Fix various type-conversion warnings - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5733
http://codereview.appspot.com/559450053

5705 Silence warning in Stem::get_beaming () - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5705
http://codereview.appspot.com/565610043

5670 lily: fix some type conversion warnings - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5670
http://codereview.appspot.com/557190043



 Review:

5718 Grow heap aggressively during music interpretation - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5718
http://codereview.appspot.com/561390043

5709 Use a pointer for the output parameter of Lily_lexer::scan_word - 
Han-Wen Nienhuys

https://sourceforge.net/p/testlilyissues/issues/5709
http://codereview.appspot.com/577440044



 New:

5738 Doc: Some miscellaneous suggestions from Peter Toye - xmichael-k
https://sourceforge.net/p/testlilyissues/issues/5738
http://codereview.appspot.com/579280043



 Waiting:

5688 Announce end of multi-measure-rest - Han-Wen Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5688
http://codereview.appspot.com/561310045

4943 Manual page breaking causing assertion failure - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/4943

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Dan Eble]

On Feb 5, 2020, at 20:26, Thomas Morley  wrote:

> So to repeat myself, everyone should take his post literal, not offending!
> 
> I'd love to see a community bearing different personalities, even
> personalities with problematic conversation skills.
> For me it's like strange english from a non-native speaker (like me).
> It's sometimes difficult and/or tedious to understand but mostly worth
> the attention.
> 
> Well, long mail for a non-native speaker, and I still have the feeling
> I didn't express myself very well.
> Though, I did the best I could.
> 
> Thanks,
>  Harm

I also want to put in a kind word for David K. and point out that Harm's 
attempt to de-escalate this conversation demonstrates that the ideas of 
mentorship and teamwork that have been circulating with regard to technical 
matters are also applicable to interpersonal matters.
— 
Dan

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Karlin High]

I've been following Lilypond mailing lists since 2016 or so. I'd
describe my most common role as "entry-level tech support," answering
the most basic mailing list questions so better-skilled people don't
have to deal with them.

I can point to the exact thread(s) that drew me into the Lilypond
community. (keywords: mclaren prime tuplets) The outstanding feature
to me was its handling of conflict.



In that thread, it was as if someone had read the Dale Carnegie "How
To Win Friends and Influence People" book and then behaved the exact
opposite of everything the book teaches. David Kastrup has often been
criticized for lacking "soft skills" with people. But there I noticed
he kept offering help (well-wrapped in sarcastic rebukes, I grant)
after many "nicer" people had lost their tempers and were calling for
the offending user's head.



I could easily spill 800 words on the Code of Conduct proposal. But
Carl Sorensen's posts already pretty much captured what I'd have to
say. The only thing I'll add is that according to this article on
SourceForge, a lack of project contributors is not in any way unique
to LilyPond, or likely to be much solved by adopting a Code of
Conduct:

"
Open Source Is Growing, But Not How It Should

...According to a recent survey from Stack Overflow only a mere 12.4%
of respondents said they contribute to open source at least once a
month or more often, and 23.1% said they contribute more than once a
year but not monthly. The rest of the respondents, which constitute
more than half, said they contribute less than even once a year or not
at all...
"


I agree with Mike Solomon's conclusion that the Contributor Covenant
Code of Conduct is not a good fit for the Lilypond project, in the
state they are each currently found. I don't disagree in principle
with the effort to have something like that, though. I just came
across the one on GitLab's forum today and was favorably impressed.


If a project reform effort is desired, I think the code contribution
workflow is a much better choice. Pretty much everyone agrees that
what we have isn't good. I'd really like to see the issue tracker,
code review, and repository all together in one place. GitLab looked
good in a previous thread researching it, but I have no emotional
investment in anything here.

My personal story of contributor experience: I have done one patch,
ever. It wasn't easy. But that's not really anyone's fault. In fact,
the lilypond-devel list was outstanding in support efforts; I consider
it my collective mentor. Lilypond is just a HARD project. Converting
plain text to beautiful sheet music, what else to expect? It needs
music theory, music engraving, computer science, C++, Guile, Python,
Bison, PostScript, fonts, MetaFont, Texinfo... the list just goes on.
Following the Lilypond mailing lists has taught me more about music
than most anything else, but I simply don't currently have the skills
for being a big contributor. My formal education stopped at 8th grade.
I had lots of computer time in late teen years, but it was Windows 98,
Microsoft Office, and Visual Basic for Applications. A Knoppix Live CD
entered the picture eventually, and I've enjoyed Linux ever since. But
usage habits had already been formed. I find Unix-world text editors
and Git interesting, but intimidating. I'd probably do well to learn
them, but as stratechery.com Ben Thompson says, once something's
getting the job done for someone, it needs a 10X improvement to get
them to switch to something else. For most any Lilypond code I want to
work on, it seems I need to research a fair list of foundational
concepts first. I actually enjoy doing that, but a self-employed
father of five (oldest age 11) can only do so much for hobby projects.
At my state in life, it's hard to study up on something before the
need arises for it.

For me, another big barrier to contributing is simply not knowing
what's a good area to work on. The single biggest thing I've seen
working to get people contributing is inviting them into a definite
effort with clear instructions. Example: Knut Petersen's "Please Test
GUB" thread from a year ago, which got about 16 people helping on one
of the thorniest parts of the entire project.


Another thing: I don't see any substitute for having full-time
developers. I was following the list for a long time before I realized
that David Kastrup's position depends on financial support from the
community, or how people could contribute that way. Currently, the
Lilypond website's "Sponsoring" page says nothing about this.
 I'd like to see that changed so
that anyone with Git commit privileges and a flexible schedule

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Graham,

> Oh, that would definitely be a good idea!

Okay, then! I’ll start with your suggestion to [paraphrasing:] "summarize the 
jobs described in the CG", and prepare a skeleton document where each entry is 
like that one.

> (I'm not quite certain about the "Receives From" and "Passes To"
> lines, as I think that implies a more formalized process than LilyPond has

Those would be more for understanding the flow of the process, and figuring out 
where combinations/elisions can happen (e.g., someone might have sufficient 
skill and interest to be both Patch Submitter and Patch Formatter), and where 
automation can help (e.g., code formatting LOL).

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: development process

[Kieren MacMillan]

Hi again,

> Let's pick one person: Han-Wen.  He's said that he has a few hours
> to spend on LilyPond on Friday afternoon.  Would he prefer to work
> on resolving comments about his latest patch on scheme internals
> (or whatever he's working on) ?  Or would he prefer to spend time
> communicating with his "paired" developer, who's excited about the
> shape of the alto clef and wants to work on that instead?
> 
> I can't answer that question, and neither can you.

I didn’t try to, and don’t want to.

> Han-Wen is the only person who can decide how he'd like to spend his time.

Correct. I’m not suggesting anybody has to do anything they don’t want to do, 
or have any decision made for them.


My syllogism [on this particular focused topic] is simply this:

1. A problem in the past has been patches "dropping off".

2. One of the things that could help (and certainly couldn’t harm) keeping a 
patch moving forward is if every patch were [co-]signed out by a (i.e., at 
least one) developer who is capable of taking that patch to the goal line. 
Conversely, every patch signed out only by one or more developers *incapable* 
of taking it to the goal line is another patch with the distinct possibility of 
taking up (read: wasting) valuable resources (time in review, commenting, etc. 
by higher-level developers) during the process, and ultimately "dropping off".

3. It is worth discussing whether instituting such a system/restriction would 
provide a net benefit to the overall development process and experience.


If one of those premises, or the logical steps/deduction between them, is 
flawed in some way, please let me know. Also, if somewhere in those three steps 
I’ve suggested — explicitly or implicitly — that (e.g.) Han-Wen wouldn’t be 
able to fully make his own decision on how to spend his time, please point that 
out to me.

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Graham Percival]

On Wed, Feb 05, 2020 at 09:24:37PM -0500, Kieren MacMillan wrote:
> Job: Patch Formatter
> Tasks: Ensure that a submitted patch conforms to the Lilypond code standards 
> (found  and  and ).
> Requirements: a text editor; working knowledge of the programming language(s) 
> used in a given patch (possibilities: C++, Scheme, python).
> Estimated Time Commitment: 5 minutes (per average patch), currently an 
> average of 7 patches per week
> References & Links: ,  tools here>, etc.
> Receives From: Patch Submitter or Patch Reviewer
> Passes To: Patch Reviewer

Oh, that would definitely be a good idea!

(I'm not quite certain about the "Receives From" and "Passes To"
lines, as I think that implies a more formalized process than
LilyPond has, but the rest would be *fantastic*!)

Cheers,
- Graham

Re: development process

[Kieren MacMillan]

Hi Graham,

> Thought experiment: suppose that a complete newcomer posts to the
> email list tomorrow, saying that he was interested in working on
>bug #5542 cross-staff slur hides text in eps backend
> (I picked randomly).
> 
> Would anybody jump up and say "great!  Let me help you get
> started.  I'll work on this with you!"?  Or would there be silence
> for a few days?
> 
> If you say "I expect that a developer (but not me) would step
> forward and offer to mentor him"... then you would be expected
> extra volunteer effort from developers.

I wouldn’t (and didn’t) say or expect that at all.

What I *am* saying is this: I’d bet good money that if Joe Newcomer** wasn’t 
allowed to even start work on bug #5542 until Capable Developer stepped forward 
and "co-signed" for the patch — effectively guaranteeing it has at least the 
*technical* possibility of making it to the goal line — there’d be a lot fewer 
newbies frustrated when their patches, which they spent many hours coding, 
"dropped off" during the later stages (review, push, etc.) of the process, 
which is what you explicitly pointed out has been a problem in the past.

Cheers,
Kieren.

** Joe Newcomer was the commissioner of "The Gray Cat & The Flounder", an 
evening-length "theatre of music" piece I wrote in 2015. I hope this post ends 
up in future web searches for Joe.  =)



Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: development process

[Graham Percival]

On Wed, Feb 05, 2020 at 08:59:33PM -0500, Kieren MacMillan wrote:
> > LilyPond has had a lot of patches get dropped because
> > nobody feels comfortable reviewing / shepherding them.
> 
> Seems to me like one solution to that problem might be a subtle
> variant on extreme programming: All features/fixes must be
> signed out for "patch-ing" by two developers, at least one of
> which has committed to and is capable of being the mentor
> (shepherding/reviewing).

If LilyPond development were a job (which it isn't), and I was the
manager/boss (which I'm not), then I would be totally on board
with ordering experienced developers to spend 20%-30% of their
time mentoring.  This "pair programming" solution is one such
version.

But LilyPond isn't a job.  It's a volunteer effort, and people are
free to donate their time (or not) as they see fit.

Let's pick one person: Han-Wen.  He's said that he has a few hours
to spend on LilyPond on Friday afternoon.  Would he prefer to work
on resolving comments about his latest patch on scheme internals
(or whatever he's working on) ?  Or would he prefer to spend time
communicating with his "paired" developer, who's excited about the
shape of the alto clef and wants to work on that instead?

I can't answer that question, and neither can you.  Han-Wen is the
only person who can decide how he'd like to spend his time.


I would *love* to see more developers collaborating together.  But
if the current landscape is anything like it was from 2000 - 2012,
then I fear that any policy which *required* such collaboration
would likely lead to a collapse of development effort.

My $0.02: developers can already form pairs, or take newcomers
under their wing, or do any number of activities that involve
collaborating off-list.  I tried to set up "programming mentoring"
at least twice, and it always fizzled out.

If there's more developers interested in mentoring, and if they
can get a real community of mentoring going for a few months,
*then* I think it might be worth formalizing such arrangements in
policy.  But unless / until that happens, I would be reluctant to
have a policy that required collaboration which we don't see
happening already.


Thought experiment: suppose that a complete newcomer posts to the
email list tomorrow, saying that he was interested in working on
bug #5542 cross-staff slur hides text in eps backend
(I picked randomly).

Would anybody jump up and say "great!  Let me help you get
started.  I'll work on this with you!"?  Or would there be silence
for a few days?

If you say "I expect that a developer (but not me) would step
forward and offer to mentor him"... then you would be expected
extra volunteer effort from developers.

Cheers,
- Graham

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Werner LEMBERG]

David,


> [...] the principal impact to be expected on LilyPond development
> appears to have an official body entitled to censure my behavior and
> eventually, out of a sense of duty, remove me.

I won't definitely do that.

> The general stance of the GNU project on its internal lists is to
> rely more on education and admonishment than official committees,
> censure, and exclusion.

Yep.


Werner

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Werner LEMBERG]

[Being on the return from Hawaii I'm late with everything, so please
 don't be surprised if I answer to stuff that has already been
 discussed to death.]

> The preamble and intent is one thing; adding a corrective committee
> with the authority to enact punishments based on anonymous reports
> is another.  It implements hierarchies and institutions exerting
> coercive power based on incomplete and secret information.  That is
> inherently an entity offering an opportunity for "pulling strings".
> I am not really a fan of constructs with a life and dynamics of
> their own.

Indeed.  Norbert Preining, one of the TeXLive maintainers (I know him
personally) and maintainer of TeXLive in Debian, was victim of exactly
such a process.[1] He got banned being a Debian developer, and it was
never explicitly explained to him why.

So what about having a CoC without the 'corrective committee'?  Up to
now this worked quite nicely.


Werner

[1] https://lists.debian.org/debian-project/2018/12/msg00032.html

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi again, Graham:

More concretely… Where can I go, in the CG or elsewhere, to find something that 
looks like this:

Job: Patch Formatter
Tasks: Ensure that a submitted patch conforms to the Lilypond code standards 
(found  and  and ).
Requirements: a text editor; working knowledge of the programming language(s) 
used in a given patch (possibilities: C++, Scheme, python).
Estimated Time Commitment: 5 minutes (per average patch), currently an average 
of 7 patches per week
References & Links: , , etc.
Receives From: Patch Submitter or Patch Reviewer
Passes To: Patch Reviewer

?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Thomas Morley]

Am Do., 6. Feb. 2020 um 02:55 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:

> > I'd like to recommend that everyone argues with him, if you think he is 
> > wrong.
> > Otherwise take his posts literal and _not_ offending.
>
> Not everybody likes to argue.  So yes, I felt in a comfortable space
> with you and it was a productive exchange where I was not aware of any
> potential for controversy.

Same on my part.

> But I'll agree that it sends an awful
> message to bystanders.
>
> I'll have to sleep over what that means.  While your recommendation is
> certainly not a bad idea as such, it does not help reducing the impact
> on first visitors.
>
> Thanks for that exposition.  It was certainly relevant for bringing some
> insight to my side of the fence.

You're welcome :)

Best,
  Harm

Re: development process

[Kieren MacMillan]

Hi Graham (et al.),

> LilyPond has had a lot of patches get dropped because
> nobody feels comfortable reviewing / shepherding them.

Seems to me like one solution to that problem might be a subtle variant on 
extreme programming: All features/fixes must be signed out for "patch-ing" by 
two developers, at least one of which has committed to and is capable of being 
the mentor (shepherding/reviewing).

The [well-documented] benefits of extreme programming should decrease poor 
design choices out of the gate, reduce the number of errors, make the whole 
process go faster, and guarantee that the "coding team" has the skills and 
commitment to take it to the goal line [assuming the rest of the process is 
relatively smooth and the gatekeepers receptive].

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Thomas Morley  writes:

> As an example look at the review of one of my own patches
> https://codereview.appspot.com/270640043
> Quoting dak:
> "This looks like a total mess."
> "Total waste of effort."
> "Aaand another one."

Ouch.  Fortunately in context this looks less dire ("Aaand another one."
for example just means "And here is another thing I found after looking
more carefully.").  Those sentences are part of a larger line-by-line
review and more or less the cream of the crop.

But yes, read in isolation and not sorting it into the somewhat jovial
overall tone, that's bad.  And one problem is that even if the recipient
happens to know how to take it, that's not a given for other readers
looking for examples of how reviews go.

> Ofcourse quotation is without any context (you may red it up, if you want)
> You can _interpret_ this as trashing my patch at the worst,

If that were the only lines, yes.  There is lots of detailed stuff and
suggestions in between, interspersed with questions about the aim of the
patch because I suspect it can be done achieved a lot more simple (a
hunch that often holds when things are converted to polar coordinates
and back again).

> but  I'm
> used to take his posts literal, i.e.:
> It _was_ a "total mess" -> I improved the patch

The mess was likely the bunch of expressions involved and their flow.

> I argued against "waste of effort" -> convinced him

Waste of effort was a sequence of scaling up and scaling down again by
the same factor, but I overlooked that a different scale factor at a
different angle also came into play so that this was more complex than
it looked.

Again, "waste of effort" did not refer to the patch but rather about
what the computer was doing.  I, well, am better at empathising with
computers than humans when looking at programs.

> And there _was_ another issue -> I improved the patch
>
> Finally the patch came through.
>
> I'd like to recommend that everyone argues with him, if you think he is wrong.
> Otherwise take his posts literal and _not_ offending.

Not everybody likes to argue.  So yes, I felt in a comfortable space
with you and it was a productive exchange where I was not aware of any
potential for controversy.  But I'll agree that it sends an awful
message to bystanders.

I'll have to sleep over what that means.  While your recommendation is
certainly not a bad idea as such, it does not help reducing the impact
on first visitors.

Thanks for that exposition.  It was certainly relevant for bringing some
insight to my side of the fence.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Nalesnik]

On Wed, Feb 5, 2020 at 7:37 PM Thomas Morley  wrote:
>
> Hi all,
>
> Being on the lists for many years now I remember only a few posts
> which were inappropriate:
>
> Long time ago. there was a user with a post others felt uncomfortable
> with. But Graham denied a problem. But there was a followup which
> definitely was.
> And Graham told the user that it was not appropriate. As a result the
> problem was cured.
>
> I once told a user myself not to write about politics. As a result the
> problem was solved.
>
> There was a user definitely offending all, especially developers.
> Several complaints were posted, even the list-admin was called, but he
> didn't ban him. Iirc, he recommended everyone who can't bear him, to
> set him on a blacklist. I may recall wrongly, but that's what I
> finally did.
> Sometime later this user stopped posting...
>
> If I remember correctly these are _all_ problematic posts (ofcourse I
> may have missed some)
> Do we need a CoC for them?
> I doubt.
> While I think that the proposed CoC-behaviour should be naturally, I'm
> uncomfortable with the proposed consequences for violating it. At
> least in the past we got back on track more or less pretty easily,
> without CoC.
>
> Now to David and his communication.
> I'm aware people often feel offended by him.
> Though, we all know or at least should know about his communication
> problems, I'm absolutely sure he knows about them, likely better than
> we.
>
> I always found that most of the bad feelings resulted of misunderstandings.
> Sometimes David misunderstood, and replied strange. Once his
> misunderstanding is cleared he usually corrects his post.
> Sometimes the recipient of his post _misunderstands_ a post as
> offending, while it is meant most simply as a description or
> recommendation.
>
> As an example look at the review of one of my own patches
> https://codereview.appspot.com/270640043
> Quoting dak:
> "This looks like a total mess."
> "Total waste of effort."
> "Aaand another one."
>
> Ofcourse quotation is without any context (you may red it up, if you want)
> You can _interpret_ this as trashing my patch at the worst, but  I'm
> used to take his posts literal, i.e.:
> It _was_ a "total mess" -> I improved the patch
> I argued against "waste of effort" -> convinced him
> And there _was_ another issue -> I improved the patch
>
> Finally the patch came through.
>
> I'd like to recommend that everyone argues with him, if you think he is wrong.
> Otherwise take his posts literal and _not_ offending.
>
>
>
>
> Am Do., 6. Feb. 2020 um 00:32 Uhr schrieb Janek Warchoł
> :
>
> > śr., 5 lut 2020 o 14:41 David Kastrup  napisał(a):
> >
> > > Janek Warchoł  writes:
> > > > In short, it's been found (I think Mike will be able to give you 
> > > > specific
> > > > examples) that having code of conduct encourages contributions from
> > > > newcomers.
> > >
> > > I rather think that a friendly atmosphere encourages contributions from
> > > newcomers.  Whether an upfront requirement to commit to a set of rules
> > > with an enforcement team is perceived as a guarantee of a friendly
> > > atmosphere is debatable. [...]
> > > the principal impact [of Code of Conduct] to be expected on
> > > LilyPond development appears to have an official body entitled to
> > > censure my behavior and eventually, out of a sense of duty, remove me.
> > >
> >
> > Do you think that approaching other people with suspicion like this (i.e.
> > expecting they have worst intentions, which is getting close to a
> > conspiracy theory) contributes to a friendly atmosphere? I don't think so.
>
> I would take David post _literal_
> He simply told us from his previous bad experiences and his feelings
> it may happen again here, now based on the proposed CoC.
>
> I would be very sad to loose him.
>
> > And honestly, I'm very sorry to read something like this from you. It made
> > me regret coming back to the project, and almost made me want to resign
> > again.
>
> I would be very sad to loose you (again) as well!
> Janek, I always had the feeling you love a community with all people
> "on the same track", though David is "special".
>
> So to repeat myself, everyone should take his post literal, not offending!
>
>
> I'd love to see a community bearing different personalities, even
> personalities with problematic conversation skills.
> For me it's like strange english from a non-native speaker (like me).
> It's sometimes difficult and/or tedious to understand but mostly worth
> the attention.
>
>
> Well, long mail for a non-native speaker, and I still have the feeling
> I didn't express myself very well.
> Though, I did the best I could.
>

+1

Thank you, Harm.

The other David

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Carl,

> More sources:
> http://lilypond.org/doc/v2.19/Documentation/contributor/meisters
> http://lilypond.org/doc/v2.19/Documentation/contributor/the-bug-squad

Thanks! Very helpful links.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi David,

> My own current concern, as explained in Salzburg

I enjoyed your talk very much.

> is to facilitate completely independent "zones of genius" for the kind of
> half-user/half-programmer that embodies "power users" on the user list,
> people developing complex solutions and engravers in Scheme.

Yes. I’m 100% on board with that. But I personally need to see a complete list 
of granularized tasks/jobs before I can even figure out where *I* best fit in, 
never mind where someone I just met on-list might fit in.

> It won't address the issues we are currently discussing with regard to
> coordinating changes to the core that have the potential to affect
> everyone

I disagree: my whole point is to get a full, highly-detailed "map" of the 
entire ecosystem, core and non-core, so that the discussion can move forward in 
a more rational way.

> With regard to the core, my main approach to the "zones of genius"
> problem is not as much adding functionality but trying to modularize and
> automate interactions between various typesetting elements in a manner
> where they become more predictable and the tendency diminishes to have
> things falling apart on one end as one adds on the other.

That’s a *technical* goal. I’m working on an *organizational* goal [which, 
hopefully, fully supports your technical goal and eases the path to success].

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Graham,

> If you want "extreme granularity", then wouldn't that be the whole 
> Contributor's Guide?

Well, (a) for starters 'no'… ;) and (b) even if 'yes', it sure wouldn’t be best 
presented in that format.  ;)

> I suspect that you want a "less extremely granular" list

No. I want what I asked for: a hyper-granular list like

   Patch-Related Jobs:
   Patch Coding
   Patch Mentoring
   Patch Optimization
   Patch Documentation
   Patch Formatting
   Patch Submission
   Patch Shepherding
   Patch Testing
   Patch Review
   Patch Approval
   Patch Pushing
   Patch Confirmation

etc., in which, for example, Patch Testing and Patch Review are two different 
jobs. Also note that "Patch-Related Jobs" might represent only 1/5th of the 
total number of jobs in the ’Pond.

>  1) summarize the jobs that are described in the CG
>  2) check if those descriptions are still accurate

I’m happy to start there. I just wanted to make sure my *invention* of the 
wheel wasn’t *re-*.  :)

> I suspect that "automation tools" would be the most impactful improvements.

Of what job(s)? If we don’t know all the steps, how they combine, how many 
people can/do execute them, and what the precise toolchain options are (or 
could be), talk of automating them seems premature to me.

> I suspect that the answer is "try to find developers willing to mentor".

Mentor what, exactly? If someone came along whose expertise and interest was 
solely in regression testing, and they wanted desperately to contribute to 
Lilypond, we should put them in that job [only?] — the amount of "mentoring" 
would essentially be zero, since [if the correct systems and processes were in 
place] they could do their job without doing literally any other task (i.e., 
someone else would provide them with a compiled binary in any desired version, 
someone else would take their regression test results and interpret and/or 
upload them, etc.).

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Thomas Morley]

Hi all,

Being on the lists for many years now I remember only a few posts
which were inappropriate:

Long time ago. there was a user with a post others felt uncomfortable
with. But Graham denied a problem. But there was a followup which
definitely was.
And Graham told the user that it was not appropriate. As a result the
problem was cured.

I once told a user myself not to write about politics. As a result the
problem was solved.

There was a user definitely offending all, especially developers.
Several complaints were posted, even the list-admin was called, but he
didn't ban him. Iirc, he recommended everyone who can't bear him, to
set him on a blacklist. I may recall wrongly, but that's what I
finally did.
Sometime later this user stopped posting...

If I remember correctly these are _all_ problematic posts (ofcourse I
may have missed some)
Do we need a CoC for them?
I doubt.
While I think that the proposed CoC-behaviour should be naturally, I'm
uncomfortable with the proposed consequences for violating it. At
least in the past we got back on track more or less pretty easily,
without CoC.

Now to David and his communication.
I'm aware people often feel offended by him.
Though, we all know or at least should know about his communication
problems, I'm absolutely sure he knows about them, likely better than
we.

I always found that most of the bad feelings resulted of misunderstandings.
Sometimes David misunderstood, and replied strange. Once his
misunderstanding is cleared he usually corrects his post.
Sometimes the recipient of his post _misunderstands_ a post as
offending, while it is meant most simply as a description or
recommendation.

As an example look at the review of one of my own patches
https://codereview.appspot.com/270640043
Quoting dak:
"This looks like a total mess."
"Total waste of effort."
"Aaand another one."

Ofcourse quotation is without any context (you may red it up, if you want)
You can _interpret_ this as trashing my patch at the worst, but  I'm
used to take his posts literal, i.e.:
It _was_ a "total mess" -> I improved the patch
I argued against "waste of effort" -> convinced him
And there _was_ another issue -> I improved the patch

Finally the patch came through.

I'd like to recommend that everyone argues with him, if you think he is wrong.
Otherwise take his posts literal and _not_ offending.




Am Do., 6. Feb. 2020 um 00:32 Uhr schrieb Janek Warchoł
:

> śr., 5 lut 2020 o 14:41 David Kastrup  napisał(a):
>
> > Janek Warchoł  writes:
> > > In short, it's been found (I think Mike will be able to give you specific
> > > examples) that having code of conduct encourages contributions from
> > > newcomers.
> >
> > I rather think that a friendly atmosphere encourages contributions from
> > newcomers.  Whether an upfront requirement to commit to a set of rules
> > with an enforcement team is perceived as a guarantee of a friendly
> > atmosphere is debatable. [...]
> > the principal impact [of Code of Conduct] to be expected on
> > LilyPond development appears to have an official body entitled to
> > censure my behavior and eventually, out of a sense of duty, remove me.
> >
>
> Do you think that approaching other people with suspicion like this (i.e.
> expecting they have worst intentions, which is getting close to a
> conspiracy theory) contributes to a friendly atmosphere? I don't think so.

I would take David post _literal_
He simply told us from his previous bad experiences and his feelings
it may happen again here, now based on the proposed CoC.

I would be very sad to loose him.

> And honestly, I'm very sorry to read something like this from you. It made
> me regret coming back to the project, and almost made me want to resign
> again.

I would be very sad to loose you (again) as well!
Janek, I always had the feeling you love a community with all people
"on the same track", though David is "special".

So to repeat myself, everyone should take his post literal, not offending!


I'd love to see a community bearing different personalities, even
personalities with problematic conversation skills.
For me it's like strange english from a non-native speaker (like me).
It's sometimes difficult and/or tedious to understand but mostly worth
the attention.


Well, long mail for a non-native speaker, and I still have the feeling
I didn't express myself very well.
Though, I did the best I could.

Thanks,
  Harm

Re: ’Pond Jobs & Their Descriptions

[Graham Percival]

On Wed, Feb 05, 2020 at 06:55:38PM -0500, Kieren MacMillan wrote:
> I’m curious as to all the various jobs/tasks required to keep
> Lilypond development moving forward at the fastest possible pace
> and in the most efficient possible way.  Is there a single list
> compiled anywhere, written with an eye to extreme granularity?

If you want "extreme granularity", then wouldn't that be the whole
Contributor's Guide?

> If not, I’ll start a list, brainstormed from my naïve perspective.

I suspect that you want a "less extremely granular" list, in which
case I suggest:
  1) summarize the jobs that are described in the CG
  2) check if those descriptions are still accurate

> (b) identify the most important gaps or under-addressed areas in the 
> pipeline; and

I suspect that "automation tools" would be the most impactful
improvements.

> (c) help new developers find the best way in to the 'Pond.

I'm not up to date on current LilyPond, but I suspect that the
answer is "try to find developers willing to mentor".

Cheers,
- Graham

Re: ’Pond Jobs & Their Descriptions

[Carl Sorensen]

On 2/5/20, 4:55 PM, "lilypond-devel on behalf of Kieren MacMillan" 
 wrote:

Hello all!

I’m curious as to all the various jobs/tasks required to keep Lilypond 
development moving forward at the fastest possible pace and in the most 
efficient possible way. Is there a single list compiled anywhere, written with 
an eye to extreme granularity? (The closest I can find is 
, and the 9 
bullet points there are at least an order of magnitude fewer than the list I’m 
thinking of.) If not, I’ll start a list, brainstormed from my naïve perspective.

Motivation: if we collectively polish it into a clear and complete 
description of the entire Lily-dev ecosystem, we could eventually use it to:
(a) place existing developers and contributors into their Zone(s) of 
Genius;
(b) identify the most important gaps or under-addressed areas in the 
pipeline; and
(c) help new developers find the best way in to the 'Pond.

Thoughts?

Sounds like a great idea.  This is something that Graham did exceptionally well 
when he was here, IMO.

More sources:

 http://lilypond.org/doc/v2.19/Documentation/contributor/meisters
http://lilypond.org/doc/v2.19/Documentation/contributor/the-bug-squad


Carl

Re: ’Pond Jobs & Their Descriptions

[David Kastrup]

Kieren MacMillan  writes:

> Hello all!
>
> I’m curious as to all the various jobs/tasks required to keep Lilypond
> development moving forward at the fastest possible pace and in the
> most efficient possible way. Is there a single list compiled anywhere,
> written with an eye to extreme granularity? (The closest I can find is
> , and
> the 9 bullet points there are at least an order of magnitude fewer
> than the list I’m thinking of.) If not, I’ll start a list,
> brainstormed from my naïve perspective.
>
> Motivation: if we collectively polish it into a clear and complete
> description of the entire Lily-dev ecosystem, we could eventually use
> it to:
> (a) place existing developers and contributors into their Zone(s) of 
> Genius;
> (b) identify the most important gaps or under-addressed areas in the 
> pipeline; and
> (c) help new developers find the best way in to the 'Pond.
>
> Thoughts?

My own current concern, as explained in Salzburg, is to facilitate
completely independent "zones of genius" for the kind of
half-user/half-programmer that embodies "power users" on the user list,
people developing complex solutions and engravers in Scheme.  As
witnessed by their almost daily feats, they have a lot to offer in terms
of individual solutions to small, comparatively individual problems that
would warrant solutions but don't really make a lot of sense integrating
into one core offering of LilyPond.

While there are certainly more comprehensive packages worth making
independently accessible and developable (like edition engraver and much
functionality in openlilylib), the multitude of near-daily offerings
really clamors for some easy archiving and preservation mechanism making
it possible to search for stuff with keywords, have packages downloaded
after browsing their descriptions and try their effects with few lines
of invocation that are trivial to use and revert.

It won't address the issues we are currently discussing with regard to
coordinating changes to the core that have the potential to affect
everyone regardless of whether they need or exercise new added
functionality, but it would enable a large visible and potentially less
visible part of the userbase to exchange and try out solutions in a less
ad-hoc and interactive way than the mailing lists offer.

With regard to the core, my main approach to the "zones of genius"
problem is not as much adding functionality but trying to modularize and
automate interactions between various typesetting elements in a manner
where they become more predictable and the tendency diminishes to have
things falling apart on one end as one adds on the other.

That's all comparatively unsexy and more (re-)organisation and janitoral
than actual creative work.

And if you take a look at the rooms I am living in, you would not judge
me the best suited person for tidying up things, either.

Nevertheless, I feel I am pretty solitary with that kind of aim which I
consider sort of important for bringing a critical mass of contributors
in before they start repelling one another :)

-- 
David Kastrup

Re: development process

[Graham Percival]

On Wed, Feb 05, 2020 at 12:11:48AM +0100, David Kastrup wrote:
> Han-Wen Nienhuys  writes:
> > For context, I have a busy daytime job. I work 80% so I can set aside
> > a couple of hours of concentrated hacking time on Friday.

Yes.  I expect that most people knowledgeable about lilypond code
are in this situation, or have even less time available.  The
whole idea behind the "countdown" system introduced in the early
2010s (which I believe is still in effect) is to make maximum use
out of LilyPond experts who only have a few free hours per week.

Suppose that an expert has 2 hours of time on Friday, and maybe 10
minutes per day to skim emails for the rest of the week.  The idea
is that you can quickly see the patches that are nearing
acceptance, review them, and warn if they make any bad changes.

That's why the "countdown" system has multiple stages -- it was
designed to take at least 72 hours (IIRC) from submission to git
master, precisely to allow infrequent-but-expert developers a
chance to spot mistakes before they got into git.


> >We use “we’ll push if there are no complaints” for contributions. I
> >think this is harmful to contributors, because it doesn’t give 
> > contributors
> >a clear feedback mechanism if they should continue down a path.
> 
> They get feedback when the code is getting reviewed.  If code does not
> get reviewed, having their changes dropped on the floor is not going to
> increase their enthusiasm.

Yes.  And unfortunately, LilyPond has had a lot of patches get
dropped because nobody feels comfortable reviewing / shepherding
them.

That could be avoided if the community demanded that expert
developers spend more time reviewing patches and mentoring
beginners... but that would be horribly insulting to those
developers.  If somebody has volunteered x hundred hours, then
wishes to follow other persuits, the community should thank them
for their effort and wish them well.

> >It is harmful to the project, because we can end up adopting code
> >that we don’t understand.  -

That's true.

It's not an easy place to be in:
- there's not enough experienced developers who want to mentor
  newcomers [1].
- if it's too easy to get code in, stuff will break.
- if it's too hard to get code in, few people will want to
  contribute.

I'm not claiming that the current situation is the ideal balancing
point, but we were aware that it was a compromise solution.

[1] there's good reason for that -- my experience from the grand
documentation project is that approximately 25% of contributors
reached the "break-even" point (compared to me simply writing all
the docs myself) [2].  Based on my investigation into similar
projects (GNOME, google summer of code, etc., around 2012), that
figure is normal.

[2] of course, some of those 25% have gone on to do an incredible
amount of work, so I consider the project to have been a great
success.  Still, I can see how it can be demoralizing for a
developer to put hours into mentoring a newcomer who ends up
contributing only one or two small patches.

> The current scripts were designed to work with Google Code,

Yes.  I wish that github was FSF or GNU approved, or that there
were other tools of the same quality.

Cheers,
- Graham

’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hello all!

I’m curious as to all the various jobs/tasks required to keep Lilypond 
development moving forward at the fastest possible pace and in the most 
efficient possible way. Is there a single list compiled anywhere, written with 
an eye to extreme granularity? (The closest I can find is 
, and the 9 
bullet points there are at least an order of magnitude fewer than the list I’m 
thinking of.) If not, I’ll start a list, brainstormed from my naïve perspective.

Motivation: if we collectively polish it into a clear and complete description 
of the entire Lily-dev ecosystem, we could eventually use it to:
(a) place existing developers and contributors into their Zone(s) of Genius;
(b) identify the most important gaps or under-addressed areas in the 
pipeline; and
(c) help new developers find the best way in to the 'Pond.

Thoughts?
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Remaining sprint for the release of version 2.20

[David Kastrup]

Whatever else may be on the plate, the immediate problem to be put
behind us right now is the release of 2.20.  I put specifically the
translation team and Werner into Cc.  The translation team should check
what changes of the recent release of 2.19.84 they still need to get
track of.

Werner basically is the person most affected by changes I have not yet
cherry-picked because of problems, changes that likely would be a good
idea to have in 2.20.

Those are his extensive indexing review, and reworks of several
examples.  The indexing review is hard to apply to the by now
significantly from master diverged stable/2.20, and with the reworks of
the examples I am not sure whether they need to be accompanied by
changes to the lilypond-extra archive.  At some point of time, there has
been such a requirement; I was not sure whether it persisted.  If I am
assured that this is either not an issue, or that lilypond-extra will
get the necessary treatment until we can release 2.20 (hopefully in a
week or so), I can do the required cherry-picking myself.

So let's make sure we get our last ducks in a row for closing that
long-awaited chapter.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Janek Warchoł]

śr., 5 lut 2020 o 23:47 Kieren MacMillan 
napisał(a):

> I guess what confuses me about this whole discussion/thread — starting
> with the Salzburg "roundtable", really — is how quickly it appears to
> escalate from "let’s collaboratively design an ecosystem where everyone can
> be in their Zone(s) of Genius as often as possible with the least number of
> obstacles" to "guess I gotta leave" (Mike’s already withdrawn to a certain
> degree, Han-Wen has said a few things in that direction, you’re talking
> about the conditions of leaving the project, etc.).
>
> If that’s really the atmosphere around our beloved ’Pond, (a) it shouldn’t
> surprise anyone that the developer pool is so small and tenuous, and (b) I
> can’t personally see how any CoC could possibly solve the fundamental
> issue(s).
>
> Just my 2¢, for what it’s worth given the exchange rate.
>

I'd say about 500 kilos of gold! Seriously, I think you nailed the problem,
and you did it in a better (and shorter) way than I did in the email I've
just sent.

Thanks, Kieren! :-)
Janek

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Janek Warchoł]

I'll try to speak only on the most pressing points to avoid bloating the
discussion unnecessarily.

śr., 5 lut 2020 o 14:41 David Kastrup  napisał(a):

> Janek Warchoł  writes:
> > In short, it's been found (I think Mike will be able to give you specific
> > examples) that having code of conduct encourages contributions from
> > newcomers.
>
> I rather think that a friendly atmosphere encourages contributions from
> newcomers.  Whether an upfront requirement to commit to a set of rules
> with an enforcement team is perceived as a guarantee of a friendly
> atmosphere is debatable. [...]
> the principal impact [of Code of Conduct] to be expected on
> LilyPond development appears to have an official body entitled to
> censure my behavior and eventually, out of a sense of duty, remove me.
>

Do you think that approaching other people with suspicion like this (i.e.
expecting they have worst intentions, which is getting close to a
conspiracy theory) contributes to a friendly atmosphere? I don't think so.

And honestly, I'm very sorry to read something like this from you. It made
me regret coming back to the project, and almost made me want to resign
again.


śr., 5 lut 2020 o 23:05 David Kastrup  napisał(a):

> Urs Liska  writes:
> > Now that you say it I recall what triggered my comment in the first
> > place (I got distracted while writing and was somewhat confused
> > afterwards).
> >
> > Indeed it was the kind of unpleasant discussion about proposed changes
> > (I don't recall whether it was lilypond-devel threads or actual
> > patches, probably the former) that was the driving force. In a nutshell
> > my requests or suggestions were furiously fenced off as simply enabling
> > "single-person use cases".
>
> Uh, this was not intended as a "fence off" as much as that I considered
> extensions of that scope and direction not a good fit for putting in the
> core.
>

I know it's difficult for you, but please try to see the emotions here.
Simply notice that there is a very active contributor, to whom LilyPond as
a projects owes very much (especially when it comes to being known in
academic circles), who helped people on the lists numerous time, and this
contributor is sad and frustrated about his contributing experience.
Please, don't argue - just acknowledge the fact and try to show others that
you've acknowledged it.


śr., 5 lut 2020 o 21:47 Carl Sorensen  napisał(a):

> In your writing I sense that you have some troubles with the LilyPond
> community to which I am oblivious.  It’s not uncommon that I would be
> oblivious to such troubles.  I’d like to know more about them.
>
> [...]
>
> On the other hand, it’s not unlikely that there are problems in the
> LilyPond community that I have not noticed, and that adopting a Code of
> Conduct might draw previous contributors who noticed problems back in to
> the LilyPond community.
>
>
>
> I need to understand the problem before I’m going to be in favor of a
> change.  I’d love to be educated (this is a serious statement) about the
> problems that I haven’t noticed.
>

Carl,
thank you for being open to listening! I'll try to give examples.

I stopped contributing to LilyPond about 6 years ago. One cause of that
change was that I got a job and suddenly had much less time. But it was not
the only cause; it would have been possible for me to contribute at least a
little. The reason I did not was that participating in the development had
been too emotionally draining to endure. In my experience LilyPond has
(used to have?) huge inertia (disproportionate to the size of the project).
I mean (more or less, please consider this to be an approximation) that
when I tried doing things that didn't clearly align with the views of a
person with most authority (for the last few years David has been this
person) I had felt *unwelcome* and my personal impression was that they
were "blocked". It was very difficult to get some things done.

What Urs wrote is a very good example: even though David didn't mean to
block Urs's suggestions, that was the impression we (Urs and me) got back
then. Fortunately for LilyPond, Urs decided to start OpenLilyLib. However
in my case the result was that I ceased to contribute. I think there were
more people like me.

Another example is this very thread. See what happened here. It started
with excellent, 100% on-topic questions from Karlin High, and with very
appropriate and justified objections from Jonas Hahnfeld. However, right
after that the discussion became dominated by David, who started writing
multiple long emails, which partly consisted of merit-based question,
partly of his predictions "what will happen if" (which can be useful, but
only to certain extent) and partly of suspicions of something close to a
conspiracy theory.

Since David has more time available that many of us (who have a
non-LilyPond job), and apparently limiting email volume is not a high
priority for him, it's hard to keep up with the discussion. David produces
more 

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Wed, Feb 5, 2020 at 12:33 PM  wrote:
>
> when you see things like:
>
> World-stopped marking took 187 msecs (77 in average)
> In-use heap: 51% (40071 KiB pointers + 6357 KiB other)
>
> it means it took 187ms for GC, and then reclaimed 49% of the memory.
>
> If you often see higher percentages, we'll spend more CPU in marking memory
> without getting fresh memory.
>
> I tried to run the carver score, but it needs updating and,
>
>  [hanwen@localhost lilypond]$ ./out/bin/convert-ly  carver/*ly
> convert-ly (GNU LilyPond) 2.21.0
>
> Traceback (most recent call last):
>   File "./out/bin/convert-ly", line 413, in 
> main ()
>   File "./out/bin/convert-ly", line 387, in main
> f = f.decode (sys.stdin.encoding or "utf-8")
> AttributeError: 'str' object has no attribute 'decode'
> [hanwen@localhost lilypond]$ python2 ./out/bin/convert-ly  carver/*ly
> Traceback (most recent call last):
>   File "./out/bin/convert-ly", line 59, in 
> import lilylib as ly
>   File
> "/home/hanwen/vc/lilypond/out/lib/lilypond/current/python/lilylib.py", line
> 216
> print('command failed:', cmd, file=sys.stderr)
>   ^
> SyntaxError: invalid syntax
>
> Is there still work left for the python3 conversion?
>
>> https://codereview.appspot.com/561390043/
>>

Yes, separate issue.  Jonas, I think you should push the fix for that
one to staging: from "doesn't work" there cannot be much more of a
regression to be afraid of.

-- 
David Kastrup

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Thu, Feb 6, 2020 at 12:19 AM Han-Wen Nienhuys  wrote:

> Um, that outputs a lot. Anything in particular?
>>
>
> when you see things like:
>
> World-stopped marking took 187 msecs (77 in average)
> In-use heap: 51% (40071 KiB pointers + 6357 KiB other)
>
> it means it took 187ms for GC, and then reclaimed 49% of the memory.
>
> If you often see higher percentages, we'll spend more CPU in marking
> memory without getting fresh memory.
>
>
so the question is: are there phases in the process where the percentage
printed is high, and if so, what are they?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Wed, Feb 5, 2020 at 12:33 PM  wrote:

> > Can you do some timings with different values for GC_MAXIMUM_HEAP_SIZE
> , eg.
> >
> >  GC_MAXIMUM_HEAP_SIZE=100M
>
> Not sure if you actually mean GC_MAXIMUM_HEAP_SIZE or rather
> GC_INITIAL_HEAP_SIZE?
>
>
I mean maximum, it sets the total amount of memory. If you set the initial
heap size, it will still grow the heap, but from a larger starting point. I
am wondering

* what the amount of RAM is this score needs as a minimum,
* how much over the minimum you need to be to get decent runtime.

this could give us hints on how aggressive we should scale up the heap.

guile22-experiment w/o the growing added in this patch:
> default: ~2m33s (gc time taken: 153.316484488)
> GC_MAXIMUM_HEAP_SIZE=100M -> "GC Warning: Out of Memory!  Trying to
> continue..." (kind of makes sense because it needs ~900MB of RAM)
> GC_INITIAL_HEAP_SIZE=100M: 2m30s (gc time taken: 2.189005726; can't
> believe this)
> GC_INITIAL_HEAP_SIZE=900M: 0m59s (gc time taken: 8.895736892)
>



> > Also, it would be interesting to GC_PRINT_STATS=1 and see how much
> time is
> > spent in GC, and how much a typical GC runs reclaim across the
> process.
>
> Um, that outputs a lot. Anything in particular?
>

when you see things like:

World-stopped marking took 187 msecs (77 in average)
In-use heap: 51% (40071 KiB pointers + 6357 KiB other)

it means it took 187ms for GC, and then reclaimed 49% of the memory.

If you often see higher percentages, we'll spend more CPU in marking memory
without getting fresh memory.

I tried to run the carver score, but it needs updating and,

 [hanwen@localhost lilypond]$ ./out/bin/convert-ly  carver/*ly
convert-ly (GNU LilyPond) 2.21.0

Traceback (most recent call last):
  File "./out/bin/convert-ly", line 413, in 
main ()
  File "./out/bin/convert-ly", line 387, in main
f = f.decode (sys.stdin.encoding or "utf-8")
AttributeError: 'str' object has no attribute 'decode'
[hanwen@localhost lilypond]$ python2 ./out/bin/convert-ly  carver/*ly
Traceback (most recent call last):
  File "./out/bin/convert-ly", line 59, in 
import lilylib as ly
  File
"/home/hanwen/vc/lilypond/out/lib/lilypond/current/python/lilylib.py", line
216
print('command failed:', cmd, file=sys.stderr)
  ^
SyntaxError: invalid syntax

Is there still work left for the python3 conversion?

> https://codereview.appspot.com/561390043/
>


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: development process

[Joram Noeck]

Dear developers,

tl;dr:
 * please continue those discussions to a constructive end
 * my experience as a non successful contributor


after more than a year of (relative) abstinence from LilyPond, I enjoy
reading the current drive in both commits and discussions in the
aftermath of the Salzburg conference. (I wished I could have been there.)

I am not a LilyPond developer, so the following is more an outside
perspective. I decided to share it, because "potential new contributors"
are mentioned several times. While sometimes there are no two ways about
it, there is room for improvements and compromise, I guess. Neither the
current dev process and tools are optimal nor is it advisable to change
everything. Because I can feel some tension in the recent discussions,
I’d like to emphasize that the following is to be read in a very
friendly tone.


Experience with trying to contribute


I am working with software development every day. I wanted to contribute
to LilyPond since about 2005. It never happened and there are some reasons:

- Even after reading the CG and getting some helpful answers to
questions, I never understood how the process works.

- tools:
  - I am used to github+travisCI and to Atlassian/Bitbucket/Jira/Jenkins
and I enjoy working with those setups. But I never understood the
LilyPond toolchain and especially the path from a commit/issue to the
final change in a LilyPond version.
  - I don’t understand why
 · there are so many tools involved, lily-git, git-cl and so many
   accounts required
 · it seems so hard to compile LilyPond on an ordinary Linux machine
   i.e. why I need LilyDev
 · dependencies on clang-format or (for a long time) python3 are
   frowned upon while the dependencies on guile and GUB look much
   more complicated to me.
  - I guess (because I haven’t worked my way through the current tools),
several of the already listed tools with better integration of review
and/or issue tracking would be an improvement over the current tools.
  - At some point I needed a Google account which I didn’t want and
could not get without a cell phone.

- I experienced quite some amount of misunderstandings and in a few
cases insinuations which made it very unpleasant to invest the work to
get over the technical hurdles. I felt a bit scared away.

- According to what I read on lilypond-devel, quite frequently
suggestions end up in an undecided state where some are for and some are
against a proposal. But that is probably much less the case for patches.

That’s my very personal experience. I have some minor local patches,
some are made obsolete by recent development. In some months from now, I
might make a new attempt to understand how contributing works.


Braking things down
---

I have the impression that what is currently discussed might be too big
to be decided upon at once. There could be some merit in splitting
things into smaller decisions. I see at least these points:

1. code style conventions
   a) checking tools (astyle, clang-format), for scm or python?
   b) changes only for new code?
   c) and their level of enforcement (hooks, review process, …)
2. tools for git, review, issue tracking, release management
   pros and cons have been mentioned for several options, but even
   if there is nothing new, a systematic assessment could help
3. development process / code of conduct
   a) number of stages from a proposed patch to a final change
   b) decision process and who decides what
   c) formal rules vs. consensus

I am sure I missed some important points here.


Even if it doesn’t matter at all, my personal choices would be:
- tools: github+jenkins, but very open to gitlab and others
 definitely clang-format over astyle (just my experience)
 I moved once from trac to github.
- less manual work in cherry-picking, testing, linking commits to issues
- much more openness towards change
- a clearer description how decisions are made and who decides while
still preferring to keep a community mindset over a strict rule set.

Many thanks to all developers for making LilyPond what it is and I wish
that you can see those discussions as a fruitful way to improve things.
In my opinion it matters for potential new developers.

Cheers,
Joram

Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)

[thomasmorley65]

Hi Dan,

I've difficulties to understand what this is about. And my lack of
C++-knowledge hinders my to deduce it.
Could you give a ly-code-example which is not possible with current
possibilities or where using current possibilities leads to some
uglyness?



https://codereview.appspot.com/581600043/

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Kieren MacMillan]

Hi David (et al.),

> I am afraid that to some degree I am oblivious of
> out-of-line behavior unless it hits me in the face.

Which simply means that calling other people in on potentially problematic 
behaviour shouldn’t fall under your job description. No biggie!

> There are multiple factors at play here.  Some concern what tools to
> move forward to, some concern how the human interaction or its avoidance
> should be structured for best effect.  If necessary, getting roadblocks
> eliminated.  The tooling and project structure and architecture are not
> entirely independent from the roles assigned to humans, so the blocked
> gates are also connected to persons' roles and characters.

Agreed.

> I am not in the position where I feel I could leave the project in good
> conscience without reneging on reasonable expectations of people
> supporting me.

I guess what confuses me about this whole discussion/thread — starting with the 
Salzburg "roundtable", really — is how quickly it appears to escalate from 
"let’s collaboratively design an ecosystem where everyone can be in their 
Zone(s) of Genius as often as possible with the least number of obstacles" to 
"guess I gotta leave" (Mike’s already withdrawn to a certain degree, Han-Wen 
has said a few things in that direction, you’re talking about the conditions of 
leaving the project, etc.).

If that’s really the atmosphere around our beloved ’Pond, (a) it shouldn’t 
surprise anyone that the developer pool is so small and tenuous, and (b) I 
can’t personally see how any CoC could possibly solve the fundamental issue(s).

Just my 2¢, for what it’s worth given the exchange rate.
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Kieren MacMillan  writes:

> Here are my thoughts, in stream-of-consciousness order:
>
> 1. There were times ca. 2014–2017 (which was a rather tough time in my
> life) in which my list behaviour should certainly have triggered an
> "issue" under any reasonably-constructed CoC. Looking back, I wish
> there *had* been a codified CoC that people (e.g., moderators) could
> have pointed me to in order to "call me in" on that behaviour.

I am afraid that to some degree I am oblivious of out-of-line behavior
unless it hits me in the face.

> 3. Just a few days ago, we were all excitedly speaking of the surge in
> development activity that arose after the [wonderful!] Salzburg
> conference; now I feel like we’re holding our collective breath
> wondering if that bubble is about to burst over a discussion of the
> benefits and drawbacks of a CoC. I take Mike’s note as the canary in
> that coal mine, and I’m personally crushed to see that it came up from
> the mine-depths dead in its bucket.
>
> 4. I really need to avoid using and mixing strange analogies and
> metaphors when I’m writing on mailing lists, especially those with
> significant international membership.  =)
>
> That’s it, really. IMO we could avoid having a CoC — at least for now
> — *and* keep developers from jumping ship (or slowly drifting away) if
> there were just a clear and agreed-upon path through/around potential
> blocked gates.

There are multiple factors at play here.  Some concern what tools to
move forward to, some concern how the human interaction or its avoidance
should be structured for best effect.  If necessary, getting roadblocks
eliminated.  The tooling and project structure and architecture are not
entirely independent from the roles assigned to humans, so the blocked
gates are also connected to persons' roles and characters.

> I can’t begin to suggest what that might look like, but my instinct
> says there are enough smart and experienced people on this list that
> we should be able to design and implement such a "safety valve" pretty
> quickly and painlessly.

I am not in the position where I feel I could leave the project in good
conscience without reneging on reasonable expectations of people
supporting me.

-- 
David Kastrup

Re: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Mittwoch, den 05.02.2020, 21:02 + schrieb pkx1...@posteo.net:
> On 05/02/2020 16:13, Dan Eble wrote:
> > On Feb 5, 2020, at 10:09, Jonas Hahnfeld <
> > hah...@hahnjo.de
> > > wrote:
> > > required to synchronize the review and the associated issue. I propose
> > > to start using GitLab hosted on gitlab.com [4] for all of this:
> > > Repository, Issues, and Merge Requests (MR) for reviews. It was
> > > evaluated 'C' in 2015 [5] and should be an 'acceptable hosting for a
> > > GNU package' [6].
> > 
> > Fine with me.  I don't expect to donate my time to make _any_ move happen, 
> > but I'd accept working with these tools to get my patches into LilyPond.  
> > It could hardly be worse than the current combination.
> > —
> > Dan
> > 
> > 
> 
> Let's assume this all 'comes to pass' what is, or how will, the 
> transition of what I do now be expected to happen?
> 
> How much (if anything) will I still need or be expected to do?

As explained in my original message, I'm not proposing changes to the
process. So for you as the Patch meister I would be "business as
usual", just with a different tool.

> These are rhetorical for now but will need consideration.
> 
> You will need suppose a testing phase and then a cut-off point from the 
> current patch review process.

I don't have a plan for this yet, this is merely a proposal to break
out from the cycle of complaining and instead discuss changes step by
step. But if we decide to pursue this direction, ultimately I guess
you're right, some cut-off needs to happen...

> (N.B. I really don't mind if the answer is that I'll be required no more 
> and I am out of a 'job' so to speak, I am not looking for empathy, all 
> that I am concerned with is that we don't end up with different 
> developers/patches working in two systems in parallel (if you see what I 
> mean), and that at the end of it all we still have the ability for 
> 'drive-by-patches' from developers or contributors whom today, just like 
> to send in git-formatted patches).

No, my hope is that you would be willing to continue your 'job',
basically implementing the process on top of the new tool. It will
certainly require some changes in the details (like using labels), but
from a high level it's hopefully the same.
In the future, we might (re-)introduce some automation to test changes
automatically. This would still leave checking the regtests and the
countdown cycle for a human, unless we also change that. But that's out
of scope, at least for me, right now.

Does this answer your questions?
Jonas


signature.asc
Description: This is a digitally signed message part

Re: Documentation suggestions.

[Michael Käppler]

Dear Peter,
it would be nice if you could register yourself at Rietveld. If you
already have a Google account it should be
straightforward, I think.
Please see the updated issue at:
https://codereview.appspot.com/579280043/



I didn't give you a very good patch - I really should have said
"Note-names in all examples in this section...". Later sections use
alterations/accidentals freely, of course.

I'm slightly worried that new users who aren't Dutch will immediately
be put off LilyPond by not understanding the very first real example,
or thinking that they have to learn Dutch names for all the musical
elements. Users of the Do-Si notation styles may like to know that
they can use their native musical language.

Ok, changed this.


>> LM 2.1.2 Pitches and key signatures. Subsection Pitch alterations.
3rd paragraph
>>         (1)after 'alterations' add 'and note-names'.
>>         (2) append:
>>
>>                 The default language for note-names and alterations
is nederlands (Dutch).
>>
>> A question: is "alterations" a good word throughout this
subsection? The normal English one is "accidentals", which is used in
the Music Glossary reference.
> IMHO, alteration applys to the underlying
> process of "altering" a note,
> which is part of the input,
> "accidental" is the graphical sign that does
> show the alteration, hence
> rather part of the rendering.

You don't think it necessary to reference the default? Maybe that
should be in

Seems a bit redundant to me. Adjusted it, nevertheless.


Hmmm. I've never heard the word 'alteration' used in this context. If
I refer (in English) to 'F sharp' I call the 'sharp' an accidental,
whether it's printed or merely played/heard. 'Alter' can refer to any
sort of change, not just semitone pitch adjustments. It might be an
ottava sign, for instance. I also note that the corresponding section
in NR 1.1.1 is titled 'Accidentals'. We should be consistent here.

Ok, Done.


I agree that accidentals aren't always alterations - they may be there
as a courtesy to the player, or even prefixed to every note whether or
not it is necessary.

>> 
>> NR 3.1.5 File Structure. Subsection Using variables. Add  a "Known
Issues"  subsection at end:
>>
>>
>>         In addition to the normal convention for variable names
[add reference to LM 2.4.1] variable names can include non-ASCII
characters and non-adjacent single underscores and dashes. Any
combination of characters is allowed if the variable name is enclosed
in double quotation marks. In this case backslashes and double
quotation marks need to be escaped with backslashes.

I mostly used David Kastrup's text here. I see that lemzwerg has
objected on the grounds that "'Alphabetic characters' and 'non-ASCII
characters' are not different sets but are overlapping".. I would
point out that LM 2.4.1 uses the term 'alphabetic', presumably meaning
[A-Z] and [a-z]. These are all ASCII characters. My text admits the
use of single underscores and dashes, lemzwerg's does not. A reference
manual shold be complete, while pointing out the difference between
best practice (Alpha) and other forms of variable name.

I like the examples he gives, but should point out that 'HornIII' is
composed entirely of ASCII characters. Maybe more useful than the
made-up Greek would be a real example- try 'Теноры'

I tried to combine Werner's and your approach.


>> ---
>> NR 1.2.5  Bars. Sub section Bar and bar number checks. Add a "known
issues" section at end:
>>
>>         If MIDI output is selected and volta repeats are in place,
the bar number check may fail. It is best to suppress MIDI output
while checking bar numbers.

I see that Dan Eble has objected to this on the grounds that bar
number checking is suppressed during MIDI output. Not in my version
(2.19.83)! That's how I discovered the issue and thought that I
couldn't count. Maybe it's a later patch. Either way, it needs
documentation here, or people will get the wrong bar numbers by accident.

It is fixed in master. The documentation that we are working on must be
valid for current master, not for older versions.
Removed it, thus.



>> --
>> NR 3.3.2 Different editions from one source. Subsection Using tags.
Add before paragraph 3 ("The arguments..."):
>>
>>         \tag, \keepWithTag and \removeWithTag are music functions
which take a music expression as their second argument. Thus they
cannot be used to filter items such as  \book or \score blocks.

I'd suggest removing 'All' from the start of your rewritten patch; it
doesn't add anything to the meaning. I'd say "Men cannot live forever"
rather than "All men cannot live forever". But "All people must die"
is OK (as a fact), has a slightly different meaning from than "People
must die" (which might be a command to an assassination squad). Not
quite sure why - it's style as much as anything else and I can't put
my 

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Kieren MacMillan]

Hi all,

I was just lurking, but now feel I should comment.

Here are my thoughts, in stream-of-consciousness order:

1. There were times ca. 2014–2017 (which was a rather tough time in my life) in 
which my list behaviour should certainly have triggered an "issue" under any 
reasonably-constructed CoC. Looking back, I wish there *had* been a codified 
CoC that people (e.g., moderators) could have pointed me to in order to "call 
me in" on that behaviour.

2. In many (most?) modern democracies, the executive and judicial branches are 
equal and separate, at least in design. In situations where that separation 
dissolves or the equality balance is tipped heavily in favour of one branch or 
the other, the rest of the [democratic] world sees it for what it is: a huge 
step backwards in the march towards overall social progress. More than a CoC, I 
feel like what the Lilypond development community needs is a check-and-balance 
system that keeps single gatekeepers from unilaterally shutting down 
non-gatekeeping contributors, a [non-partisan] Supreme Court to which an 
"ordinary citizen" can take a case against the President, if you will. Without 
the assurance that there is such a recourse, having a CoC is likely to do no 
better than the "gentleman’s agreement" that, for a few decades, kept most 
politicians from bull-running pell-mell through society’s china shops but is 
clearly no longer in play.

3. Just a few days ago, we were all excitedly speaking of the surge in 
development activity that arose after the [wonderful!] Salzburg conference; now 
I feel like we’re holding our collective breath wondering if that bubble is 
about to burst over a discussion of the benefits and drawbacks of a CoC. I take 
Mike’s note as the canary in that coal mine, and I’m personally crushed to see 
that it came up from the mine-depths dead in its bucket.

4. I really need to avoid using and mixing strange analogies and metaphors when 
I’m writing on mailing lists, especially those with significant international 
membership.  =)

That’s it, really. IMO we could avoid having a CoC — at least for now — *and* 
keep developers from jumping ship (or slowly drifting away) if there were just 
a clear and agreed-upon path through/around potential blocked gates. I can’t 
begin to suggest what that might look like, but my instinct says there are 
enough smart and experienced people on this list that we should be able to 
design and implement such a "safety valve" pretty quickly and painlessly.

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

David Kastrup  writes:


> Yes.  Even given better communication by my side.  If there are obvious
> recipes to follow to place and extend and use one's own plugin package,
> and if one so desires, submit it in a manner where other users may
> install it on-demand, I hope that the option to abandon ship will become
> not the first choice to think of.
>
> So I messed up in communicating my understanding of the best approach to
> the situation.  I don't think (or at least I very much hope so)

Talk about communication skills.  "or at least I very much _don't_ hope
so" of course.

> that this was delivered in a form that could be construed as a
> personal attack, so I have my doubts that a Coc enforcement team would
> have had much to work with here.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Urs Liska  writes:

> Am Mittwoch, den 05.02.2020, 21:21 +0100 schrieb David Kastrup:
>> Urs Liska  writes:
>> 
>> > I must say that I haven't actually expressed an opinion about it so
>> > far, and I don't know which I have.
>> > 
>> > I don't feel uncomfortable without and wouldn't mind adding it.
>> > 
>> > OTOH openLilyLib owes its existence to a nonzero part to the fact
>> > that
>> > I found it easier to do that than getting my ideas into LilyPond
>> > itself. (Although this isn't actually a comment on the CoC issue).
>> 
>> That would be relevant regarding the Code of Conduct if fear of
>> getting
>> harrassed kept you from contributing the code to LilyPond.
>
> Now that you say it I recall what triggered my comment in the first
> place (I got distracted while writing and was somewhat confused
> afterwards).
>
> Indeed it was the kind of unpleasant discussion about proposed changes
> (I don't recall whether it was lilypond-devel threads or actual
> patches, probably the former) that was the driving force. In a nutshell
> my requests or suggestions were furiously fenced off as simply enabling
> "single-person use cases".

Uh, this was not intended as a "fence off" as much as that I considered
extensions of that scope and direction not a good fit for putting in the
core.

> It was offending because the rejection was pretty personal, especially
> since the argument was explicitly and unfoundedly questioning (or
> rather denying) the usefulness of my suggestions, and I think by now I
> do have some credentials with regard to consequential usability or use
> case enhancements.
>
> I think it would count as a case falling under a CoC, but even in
> hindsight I have no idea whether having one would have helped the
> situation.

I am not sure either since the intent was to encourage keeping this in a
separately developed but easily available project.

>> It would be marginally relevant if the use of development platforms
>> was
>> under consideration where accepting/providing a particular Code of
>> Conduct was mandatory, and use of such a particular platform would
>> have
>> made working directly in the LilyPond repository more feasible.
>> 
>> For what it's worth, I do think that the bulk of OpenLilyLib likely
>> just
>> is a better fit for keeping in a separate repository/project since
>> changes in there do not need tight coordination with changes in
>> LilyPond.
>
> That's correct, and in a way this has been a lucky coincidence.

It was what I wanted to have conveyed in the first place, so it is lucky
coincidence that you ended up doing what I intended to suggest but
apparently failed.

The problem that we still need to get under wraps is that it is
non-trivial for the user to plug in and use OpenLilyLib as one of
several equal packages because the LilyPond core is missing the
infrastructure and conventions for doing this in a seamless manner.

Maybe if LilyPond could have offered something like that at the time, it
would not have appeared similarly discouraging.

> But noone could have expected that this system would take off enabling
> the development of even pretty massive extension package like the
> edition- engraver or scholarLY. And it is all but a certainty to
> expect a would- be contributor like me ending up doing that kind of
> stuff rather than just leaving ship.

Yes.  Even given better communication by my side.  If there are obvious
recipes to follow to place and extend and use one's own plugin package,
and if one so desires, submit it in a manner where other users may
install it on-demand, I hope that the option to abandon ship will become
not the first choice to think of.

So I messed up in communicating my understanding of the best approach to
the situation.  I don't think (or at least I very much hope so) that
this was delivered in a form that could be construed as a personal
attack, so I have my doubts that a Coc enforcement team would have had
much to work with here.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Urs Liska]

Am Mittwoch, den 05.02.2020, 21:21 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am 5. Februar 2020 20:08:28 MEZ schrieb 
> > nine.fierce.ball...@gmail.com:
> > > On 2020/02/05 18:17:25, c_sorensen wrote:
> > > > I recognize that Mike Solomon has a different opinion.  I mean
> > > > no
> > > disrespect to
> > > > Mike, Janek, Han-Wen, or any other member of the LilyPond
> > > > team.  I
> > > highly value
> > > > the team spirit of the LilyPond team.
> > > 
> > > Well said.  Here's the current tally as I understand it:
> > > For: Han-Wen, Janek, Mike, Urs, Werner
> > > Against: Carl, Dan, David K., Trevor
> > > Mixed: David N.
> > 
> > I must say that I haven't actually expressed an opinion about it so
> > far, and I don't know which I have.
> > 
> > I don't feel uncomfortable without and wouldn't mind adding it.
> > 
> > OTOH openLilyLib owes its existence to a nonzero part to the fact
> > that
> > I found it easier to do that than getting my ideas into LilyPond
> > itself. (Although this isn't actually a comment on the CoC issue).
> 
> That would be relevant regarding the Code of Conduct if fear of
> getting
> harrassed kept you from contributing the code to LilyPond.

Now that you say it I recall what triggered my comment in the first
place (I got distracted while writing and was somewhat confused
afterwards).

Indeed it was the kind of unpleasant discussion about proposed changes
(I don't recall whether it was lilypond-devel threads or actual
patches, probably the former) that was the driving force. In a nutshell
my requests or suggestions were furiously fenced off as simply enabling
"single-person use cases". It was offending because the rejection was
pretty personal, especially since the argument was explicitly and
unfoundedly questioning (or rather denying) the usefulness of my
suggestions, and I think by now I do have some credentials with regard
to consequential usability or use case enhancements.

I think it would count as a case falling under a CoC, but even in
hindsight I have no idea whether having one would have helped the
situation.

> 
> It would be marginally relevant if the use of development platforms
> was
> under consideration where accepting/providing a particular Code of
> Conduct was mandatory, and use of such a particular platform would
> have
> made working directly in the LilyPond repository more feasible.
> 
> For what it's worth, I do think that the bulk of OpenLilyLib likely
> just
> is a better fit for keeping in a separate repository/project since
> changes in there do not need tight coordination with changes in
> LilyPond.

That's correct, and in a way this has been a lucky coincidence. But
noone could have expected that this system would take off enabling the
development of even pretty massive extension package like the edition-
engraver or scholarLY. And it is all but a certainty to expect a would-
be contributor like me ending up doing that kind of stuff rather than
just leaving ship.

Urs

> 

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[michael . kaeppler--- via Discussions on LilyPond development]

On 2020/02/05 14:51:03, lemzwerg wrote:
> A nit.
> 
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely
> File Documentation/notation/input.itely (right):
> 
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely#newcode464
> Documentation/notation/input.itely:464: escaped with backslashes.
> This is confusing.  'Alphabetic characters' and 'non-ASCII characters'
are not
> different sets but are overlapping.  What about
> 
>   The name of a variable should not contain (ASCII) numbers,
>   underscores, dashes, or space characters.  All other
>   characters Unicode provides are allowed, for example Latin,
>   Greek, or Chinese.  In other words, variable names like
>   @code{HornIII} or @code{αβγXII} work.
> 
>   Any combination of characters is allowed if the variable name
>   is enclosed in double quotation marks.  In this case
>   backslashes and double quotation marks need to be escaped with
>   backslashes (not that you actually should use them).
>   Examples: @code{"foo bar"}, @code{"a-b-c"}, @code{"Horn 3"}.

Thank you, Werner!
I tried to combine your suggestions with Peter's remarks in
https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg00265.html

https://codereview.appspot.com/579280043/

Issue 5736: Fix input/regression/context-find-parent.ly (issue 559460043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

Reviewers: ,

Message:
Regtest differences attached to the ticket are expected.  I would
appreciate independent confirmation; is anyone interested in taking a
little time to understand the case? After that, I think it will make
sense to push this, since the code was reviewed last week and is just
enabled by this patch.

Description:
https://sourceforge.net/p/testlilyissues/issues/5736/

Enable the previously reviewed block of code required to fix this
regression test.

Please review this at https://codereview.appspot.com/559460043/

Affected files (+1, -2 lines):
  M lily/context.cc


Index: lily/context.cc
diff --git a/lily/context.cc b/lily/context.cc
index 
4fe1652751f9862908e75ce20642e6db3dc8fa1d..2a2871f32b5dbbd36afe4b0828e7e3d25138df0f
 100644
--- a/lily/context.cc
+++ b/lily/context.cc
@@ -181,8 +181,7 @@ Context::unchecked_find (FindMode mode, Direction dir,
   const bool allow_create = (mode != FIND_ONLY);
   const bool allow_find = (mode != CREATE_ONLY);
 
-  // TODO: Enabling this block will fix 
input/regression/context-find-parent.ly.
-  if (false && allow_find && (dir == CENTER))
+  if (allow_find && (dir == CENTER))
 {
   // Search everything in and below the scope of the current context first.
   // Here is an example that depends on finding a context below.

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[michael . kaeppler--- via Discussions on LilyPond development]

On 2020/02/05 14:14:47, Dan Eble wrote:
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely
> File Documentation/notation/rhythms.itely (right):
> 
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely#newcode3325
> Documentation/notation/rhythms.itely:3325: bar number check may fail. 
It is
> best to suppress MIDI output
> No.  Bar number checks are ignored by default when processing MIDI. 
See
> https://sourceforge.net/p/testlilyissues/issues/5624/ .

Ok, I will remove it. Peter's report was based on 2.19.83.


https://codereview.appspot.com/579280043/

Re: [RFC] switch to GitLab / gitlab.com

[pkx166h]

On 05/02/2020 16:13, Dan Eble wrote:

On Feb 5, 2020, at 10:09, Jonas Hahnfeld  wrote:

required to synchronize the review and the associated issue. I propose
to start using GitLab hosted on gitlab.com [4] for all of this:
Repository, Issues, and Merge Requests (MR) for reviews. It was
evaluated 'C' in 2015 [5] and should be an 'acceptable hosting for a
GNU package' [6].

Fine with me.  I don't expect to donate my time to make _any_ move happen, but 
I'd accept working with these tools to get my patches into LilyPond.  It could 
hardly be worse than the current combination.
—
Dan


Let's assume this all 'comes to pass' what is, or how will, the 
transition of what I do now be expected to happen?


How much (if anything) will I still need or be expected to do?

These are rhetorical for now but will need consideration.

You will need suppose a testing phase and then a cut-off point from the 
current patch review process.


(N.B. I really don't mind if the answer is that I'll be required no more 
and I am out of a 'job' so to speak, I am not looking for empathy, all 
that I am concerned with is that we don't end up with different 
developers/patches working in two systems in parallel (if you see what I 
mean), and that at the end of it all we still have the ability for 
'drive-by-patches' from developers or contributors whom today, just like 
to send in git-formatted patches).


James

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Carl Sorensen]

From: Mike Solomon 
Date: Wednesday, February 5, 2020 at 12:27 PM
To: "janek.lilyp...@gmail.com" , "pkx1...@gmail.com" 
, "d...@gnu.org" , "karlinh...@gmail.com" 
, "jonas.hahnf...@gmail.com" , 
Carl Sorensen , "david.nales...@gmail.com" 

Cc: "lilypond-devel@gnu.org" , 
"re...@codereview-hr.appspotmail.com" 
Subject: Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

On 2020/02/05 18:17:25, c_sorensen wrote:
That's a really good point and I see where Carl and David N are coming from. It 
seems like a Code of Conduct is not a good fit at this time. More people in the 
community would need to come around to the idea for it to work.

Maybe what I'll do is touch base in a few months and see if any opinions have 
changed, including of course my own. In the meantime, I would encourage people 
to reflect on LilyPond's shrinking number of contributions and developers and 
consider if a lack of a code of conduct could be one of the reasons it is 
difficult to grow. As a benchmark, one good place to look is the Contributors 
Covenant website. There is a list of communities that have implemented it. Ask 
the maintainers how they feel about it, cite the concerns brought up here, and 
ask if they feel it could, from their outsider perspective, be helpful for 
LilyPond. I know that, personally, I have really appreciated the code of 
conduct in projects that I have contributed to since leaving LilyPond 
development. I have also appreciated the relative ideological and demographic 
diversity of those projects, which has introduced me to perspectives about race 
and gender that are lacking in the LilyPond community.

It could of course also be the case that people are happy with the status quo 
in LilyPond, in which case it (or other things to grow the community in size 
and inclusivity) are not necessary. I personally am saddened by my own leaving, 
the leaving of others, the lack of growth and the lack of diversity, and this 
is one proposal to start changing it, but I understand the objections.

I’d be open to having my mind changed.  I think that the LilyPond community is 
poorer when Mike is not participating in it.

Mike, do you have any specific occurrences that caused you or others to stop 
participating in LilyPond development, and that you feel would be resolved (or 
resolvable) by adopting a code of conduct?  I’d be very interested in hearing 
them (preferably on the list, if you’re comfortable sharing them; or in 
private, if you’re not).

In your writing I sense that you have some troubles with the LilyPond community 
to which I am oblivious.  It’s not uncommon that I would be oblivious to such 
troubles.  I’d like to know more about them.

I think it very unlikely that implementing a Code of Conduct would draw large 
numbers of new contributors to the project.  I can’t imagine that there are 
large numbers of people running around saying “I’m looking for a project with a 
code of conduct to contribute to.”

On the other hand, it’s not unlikely that there are problems in the LilyPond 
community that I have not noticed, and that adopting a Code of Conduct might 
draw previous contributors who noticed problems back in to the LilyPond 
community.

I need to understand the problem before I’m going to be in favor of a change.  
I’d love to be educated (this is a serious statement) about the problems that I 
haven’t noticed.

Thanks,

Carl

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

"Phil Holmes"  writes:

> I've kept out of this debate for a long time because a) I've only been
> peripherally involved lately and b) there's been too much
> communication for me to read, but
>
> As one of the earlier regular committers, and as the only person who
> makes builds and updates the websites, I'd vote for no change.  No CoC
> (not needed); keep the current workflow (easy to do if follow the
> instructions), and make builds work

I do hope that we manage to get a better workflow.  "make builds work"
sounds easier than it turns out in practice: for example, at the current
point of time, GUB-made 64bit MacOSX builds are not feasible since we'd
need to change to some OpenDarwin base to even have a chance.  That will
actually not be significantly different when switching to a Guix-based
build as has been proposed: the native MacOSX SDK licenses just prohibit
execution on a non-Mac computer, regardless of the build environment.

I am cautiously optimistic that we'll be able to get out 2.20.0 soonish
and 2.21.0 afterwards.  I am more fuzzy about what that spells for
building 2.20.1 should that become necessary.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Urs Liska  writes:

> Am 5. Februar 2020 20:08:28 MEZ schrieb nine.fierce.ball...@gmail.com:
>>On 2020/02/05 18:17:25, c_sorensen wrote:
>>> I recognize that Mike Solomon has a different opinion.  I mean no
>>disrespect to
>>> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
>>highly value
>>> the team spirit of the LilyPond team.
>>
>>Well said.  Here's the current tally as I understand it:
>>For: Han-Wen, Janek, Mike, Urs, Werner
>>Against: Carl, Dan, David K., Trevor
>>Mixed: David N.
>
> I must say that I haven't actually expressed an opinion about it so
> far, and I don't know which I have.
>
> I don't feel uncomfortable without and wouldn't mind adding it.
>
> OTOH openLilyLib owes its existence to a nonzero part to the fact that
> I found it easier to do that than getting my ideas into LilyPond
> itself. (Although this isn't actually a comment on the CoC issue).

That would be relevant regarding the Code of Conduct if fear of getting
harrassed kept you from contributing the code to LilyPond.

It would be marginally relevant if the use of development platforms was
under consideration where accepting/providing a particular Code of
Conduct was mandatory, and use of such a particular platform would have
made working directly in the LilyPond repository more feasible.

For what it's worth, I do think that the bulk of OpenLilyLib likely just
is a better fit for keeping in a separate repository/project since
changes in there do not need tight coordination with changes in
LilyPond.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Phil Holmes]

- Original Message - 
From: 
To: ; ; ; 
; ; ; 
; 

Cc: ; 
Sent: Wednesday, February 05, 2020 7:08 PM
Subject: Re: Add Code of Conduct (issue 575620043 by 
janek.lilyp...@gmail.com)




On 2020/02/05 18:17:25, c_sorensen wrote:

I recognize that Mike Solomon has a different opinion.  I mean no

disrespect to

Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I

highly value

the team spirit of the LilyPond team.


Well said.  Here's the current tally as I understand it:
For: Han-Wen, Janek, Mike, Urs, Werner
Against: Carl, Dan, David K., Trevor
Mixed: David N.

Mike, you asked,

What are the blockers to making a decision about this patch?
Does it need more discussion or more buy in?


5-4 halfway through the first day doesn't look like buy-in to me.


https://codereview.appspot.com/575620043/



I've kept out of this debate for a long time because a) I've only been 
peripherally involved lately and b) there's been too much communication for 
me to read, but


As one of the earlier regular committers, and as the only person who makes 
builds and updates the websites, I'd vote for no change.  No CoC (not 
needed); keep the current workflow (easy to do if follow the instructions), 
and make builds work


--
Phil Holmes 

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Urs Liska]

Am 5. Februar 2020 20:08:28 MEZ schrieb nine.fierce.ball...@gmail.com:
>On 2020/02/05 18:17:25, c_sorensen wrote:
>> I recognize that Mike Solomon has a different opinion.  I mean no
>disrespect to
>> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
>highly value
>> the team spirit of the LilyPond team.
>
>Well said.  Here's the current tally as I understand it:
>For: Han-Wen, Janek, Mike, Urs, Werner
>Against: Carl, Dan, David K., Trevor
>Mixed: David N.

I must say that I haven't actually expressed an opinion about it so far, and I 
don't know which I have.

I don't feel uncomfortable without and wouldn't mind adding it.

OTOH openLilyLib owes its existence to a nonzero part to the fact that I found 
it easier to do that than getting my ideas into LilyPond itself. (Although this 
isn't actually a comment on the CoC issue).

Urs

Urs


>
>Mike, you asked,
>> What are the blockers to making a decision about this patch?
>> Does it need more discussion or more buy in?
>
>5-4 halfway through the first day doesn't look like buy-in to me.
>
>
>https://codereview.appspot.com/575620043/

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

On 2020/02/05 18:17:25, c_sorensen wrote:
> I recognize that Mike Solomon has a different opinion.  I mean no
disrespect to
> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
highly value
> the team spirit of the LilyPond team.

>Well said.  Here's the current tally as I understand it:
>For: Han-Wen, Janek, Mike, Urs, Werner
>Against: Carl, Dan, David K., Trevor
>Mixed: David N.

Mike, you asked,
> What are the blockers to making a decision about this patch?
> Does it need more discussion or more buy in?

>5-4 halfway through the first day doesn't look like buy-in to me.

That's a really good point and I see where Carl and David N are coming from. It 
seems like a Code of Conduct is not a good fit at this time. More people in the 
community would need to come around to the idea for it to work.

Maybe what I'll do is touch base in a few months and see if any opinions have 
changed, including of course my own. In the meantime, I would encourage people 
to reflect on LilyPond's shrinking number of contributions and developers and 
consider if a lack of a code of conduct could be one of the reasons it is 
difficult to grow. As a benchmark, one good place to look is the Contributors 
Covenant website. There is a list of communities that have implemented it. Ask 
the maintainers how they feel about it, cite the concerns brought up here, and 
ask if they feel it could, from their outsider perspective, be helpful for 
LilyPond. I know that, personally, I have really appreciated the code of 
conduct in projects that I have contributed to since leaving LilyPond 
development. I have also appreciated the relative ideological and demographic 
diversity of those projects, which has introduced me to perspectives about race 
and gender that are lacking in the LilyPond community.

It could of course also be the case that people are happy with the status quo 
in LilyPond, in which case it (or other things to grow the community in size 
and inclusivity) are not necessary. I personally am saddened by my own leaving, 
the leaving of others, the lack of growth and the lack of diversity, and this 
is one proposal to start changing it, but I understand the objections.

~Mike

Re: Issue 5739: Add makefile targets for formatting all C++ code (issue 565620043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2020/02/05 17:52:20, dak wrote:
> configure.ac:367: STEPMAKE_PROGS(CLANG_FORMAT, clang-format-9
clang-format,
> OPTIONAL, 9, 9)
> Interesting.  This gives a warning when it isn't installed?  I think
that we
> don't usually flag dependencies of components not involved in either
building or
> running LilyPond.  For example, we provide Emacs and vi style files
without
> checking for availability of either editor.

Yes, it gives a warning.  If this is a problem, IMO its is a shortcoming
of the configuration system: failing to distinguish between simply
optional programs and strongly recommended programs.  There's a similar
issue with tidy.  If it's there, we want to take advantage of it, but
warning the dev that it is missing is a nuisance.


https://codereview.appspot.com/565620043/

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[nine . fierce . ballads]

On 2020/02/05 18:17:25, c_sorensen wrote:
> I recognize that Mike Solomon has a different opinion.  I mean no
disrespect to
> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
highly value
> the team spirit of the LilyPond team.

Well said.  Here's the current tally as I understand it:
For: Han-Wen, Janek, Mike, Urs, Werner
Against: Carl, Dan, David K., Trevor
Mixed: David N.

Mike, you asked,
> What are the blockers to making a decision about this patch?
> Does it need more discussion or more buy in?

5-4 halfway through the first day doesn't look like buy-in to me.


https://codereview.appspot.com/575620043/

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[david . nalesnik]

On 2020/02/05 18:17:25, c_sorensen wrote:
> 
> On 2/5/20, 7:40 AM, "lilypond-devel on behalf of David Kastrup"
> 
> wrote:
> 
> Mike Solomon  writes:
> 
> > Janek Warchoł  writes:
> >
> >> Hi,
> >>
> >> śr., 5 lut 2020, 00:34 użytkownik  napisał:
> >>
> >>> What problem are we trying to solve here?
> >>>
> >>
> >> In short, it's been found (I think Mike will be able to give
you 
> >> specific
> >> examples) that having code of conduct encourages contributions
from 
> >> newcomers.
> >
> >> I rather think that a friendly atmosphere encourages
contributions
> >> from newcomers.  Whether an upfront requirement to commit to a
set
> >> of rules with an enforcement team is perceived as a guarantee
of a
> >> friendly atmosphere is debatable.
> >
> > I personally would feel more comfortable if there were a code of
> > conduct, and I know within my company one employee will not
attend a
> > conference or participate in a project unless there is a code of
> > conduct.  I don't have any hard stats to prove this, but have a
gut
> > feeling that a code of conduct opens more doors than it closes.
> 
> My gut feeling is the opposite.  Upon reading the Code of Conduct, it
felt to me
> like it was proposing a private channel for a mean-spirited
passive-aggressive
> person to wreak havoc on the community.
> 
> Now, I do not feel like we have any such individuals in our community.
 So in
> the best of all possible worlds, there is no harm to a code of
conduct.  But in
> the best of all possible worlds, there is also no need for a code of
conduct.
> 
> In the worst of all worlds, the lack of a Code of Conduct can lead to
individual
> bullying. In the worst of all worlds, a Code of Conduct can lead to
systematic
> bullying, where an anonymous complainer gets the weight of a
bureaucracy behind
> the bullying.
> 
> I don't believe we have the worst of all worlds.  I don't believe that
any
> individual behind the proposal for the Code of Conduct has anything
but the best
> intentions.  I want to see the LilyPond community be a friendly,
welcoming place
> for all.  I believe that it largely is a friendly, welcoming place for
all.
> 
> For me, personally, I find the Code of Conduct approach with its
implied threat
> (if you don't obey, we'll punish you -- in fact, we've spelled out the
> punishments in the document) to be much less friendly than a public
statement
> that we value an open, respectful, and friendly environment and we
call on all
> to participate in it.  The Code of Conduct approach feels like taking
a
> sledgehammer to squash a fly.

A statement about community values would be an excellent idea, but
channels for reporting and meting out punishment?  This makes me
uncomfortable.

And is this really such a large organization that we have room for
committees? 



https://codereview.appspot.com/575620043/

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Carl Sorensen]

On 2/5/20, 7:40 AM, "lilypond-devel on behalf of David Kastrup" 
 
wrote:

Mike Solomon  writes:

> Janek Warchoł  writes:
>
>> Hi,
>>
>> śr., 5 lut 2020, 00:34 użytkownik  napisał:
>>
>>> What problem are we trying to solve here?
>>>
>>
>> In short, it's been found (I think Mike will be able to give you 
>> specific
>> examples) that having code of conduct encourages contributions from 
>> newcomers.
>
>> I rather think that a friendly atmosphere encourages contributions
>> from newcomers.  Whether an upfront requirement to commit to a set
>> of rules with an enforcement team is perceived as a guarantee of a
>> friendly atmosphere is debatable.
>
> I personally would feel more comfortable if there were a code of
> conduct, and I know within my company one employee will not attend a
> conference or participate in a project unless there is a code of
> conduct.  I don't have any hard stats to prove this, but have a gut
> feeling that a code of conduct opens more doors than it closes.

My gut feeling is the opposite.  Upon reading the Code of Conduct, it felt to 
me like it was proposing a private channel for a mean-spirited 
passive-aggressive person to wreak havoc on the community.

Now, I do not feel like we have any such individuals in our community.  So in 
the best of all possible worlds, there is no harm to a code of conduct.  But in 
the best of all possible worlds, there is also no need for a code of conduct.

In the worst of all worlds, the lack of a Code of Conduct can lead to 
individual bullying. In the worst of all worlds, a Code of Conduct can lead to 
systematic bullying, where an anonymous complainer gets the weight of a 
bureaucracy behind the bullying.

I don't believe we have the worst of all worlds.  I don't believe that any 
individual behind the proposal for the Code of Conduct has anything but the 
best intentions.  I want to see the LilyPond community be a friendly, welcoming 
place for all.  I believe that it largely is a friendly, welcoming place for 
all.

For me, personally, I find the Code of Conduct approach with its implied threat 
(if you don't obey, we'll punish you -- in fact, we've spelled out the 
punishments in the document) to be much less friendly than a public statement 
that we value an open, respectful, and friendly environment and we call on all 
to participate in it.  The Code of Conduct approach feels like taking a 
sledgehammer to squash a fly.

I recognize that Mike Solomon has a different opinion.  I mean no disrespect to 
Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I highly value 
the team spirit of the LilyPond team.

I would be less likely to participate if we make the proposed Code of Conduct 
part of our LilyPond environment.

Thanks for listening,

Carl
   

Re: development process

[David Kastrup]

"Jürgen Reuter"  writes:

>Hi all,
>
>I fully agree with Han-Wen.  I also could now and then (maybe once a
>week) set aside 2-3 hours work for lily.  But the current development
>process really makes it hard for me to keep up submitting a patch (as
>part of currently 11 commits (mostly small to medium ones), partially
>with dependencies, that have been lying around locally on my machine
>for at least ~3-4 years), as I can't just "git push" my 11 commits
>after these 2-3 hours of work, and then, in my next available slot,
>maybe a week or two weeks later, look at code reviews / comments from
>other people, do a "git fetch" / "git rebase", consider the code
>reviewer's comments, and submit an updated version of the 11 commits.

It's been stated before but probably not to you in particular: you can
just send in your commits as git-formatted patches to
bug-lilyp...@gnu.org and have them entered as issues.  If there are
objections on the review that do not appear addressed, the patch meister
will stop the patch from progressing to commit state.

Even if not, I think that you have valid Savannah credentials for
pushing yourself, so unless you ask for someone else to push your
patches, you would be free to make the decision to push at your own
leisure (to origin/staging) once they have passed review and progressed
to "push" state.

In short: if you don't want to bother with the messy parts of patch
submission, there is no problem submitting your patches anyway.

All the best

-- 
David Kastrup

Re: Issue 5739: Add makefile targets for formatting all C++ code (issue 565620043 by nine.fierce.ball...@gmail.com)

[dak]

https://codereview.appspot.com/565620043/diff/549530043/GNUmakefile.in
File GNUmakefile.in (right):

https://codereview.appspot.com/565620043/diff/549530043/GNUmakefile.in#newcode319
GNUmakefile.in:319: ## TODO: This condition speeds up make when
formatting targets are not
I would not really work with a timestamp file but rather use git status
to detect modified files, so that only those would be affected.  That,
however, is more a useful approach for a script rather than a Makefile.

https://codereview.appspot.com/565620043/diff/549530043/configure.ac
File configure.ac (right):

https://codereview.appspot.com/565620043/diff/549530043/configure.ac#newcode367
configure.ac:367: STEPMAKE_PROGS(CLANG_FORMAT, clang-format-9
clang-format, OPTIONAL, 9, 9)
Interesting.  This gives a warning when it isn't installed?  I think
that we don't usually flag dependencies of components not involved in
either building or running LilyPond.  For example, we provide Emacs and
vi style files without checking for availability of either editor.

https://codereview.appspot.com/565620043/

Re: Code of Conduct

[David Kastrup]

Han-Wen Nienhuys  writes:

> A couple of people (me, Janek, Werner),  want to add a CoC to the LilyPond
> project, and there were some questions about why we would want to do that:
>
> There is a definite advantage to having a community with gentle
> interactions and without flames and personal attacks. It makes being part
> of the community more fun and rewarding, which in turn helps us attract and
> retain contributors. For almost all of us, working on LilyPond competes
> with other things in life, and if participating is net drain of emotional
> energy, those other activities will end up winning, and we'll see
> contributors leave.
>
> Having a CoC gives us a set of guidelines, a process and a set of
> corrective actions to take to help keep things nice. They are not an
> iron-clad guarantee that bad things won't happen, just as laws cannot
> prevent dictators from taking control always, but at the same time, most
> people prefer to live in societies that do have laws and means to enforce
> them.
>
> In open source projects, the BDFL model is pretty common, but if there is
> no process around how things work, the model falls apart if the BDFL
> departs. As a former Benevolent Dictator, I have been guilty of this too.
> Instituting a CoC is a tool to manage the community atmosphere that can
> outlive individuals responsible for doing so, and that spells out what the
> community can expect from those individuals.

For better or worse, a substantial part of the discussion is now on
 where the original proposal
as an addition to the LilyPond development source tree has been posted.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Mike Solomon  writes:

> Mike Solomon  writes:
>
>>> What does "implement" mean?
>>
>> Sorry, I wasn't clear. I meant merge the PR.
>
>> Uh, words have meanings.  There would be no point of putting something
> into our documentation that we are not going to follow through with.
>
> By merging it, the idea would be that the first committee of 3 started
> acting as a CoC committee.
>
> What are the blockers to making a decision about this patch?

Consent?

> Does it need more discussion or more buy in?

As the change would affect all developers and, as far as I can discern,
also users on the LilyPond user list, it would require broad consent.
Most of the potentially affected persons have not even been notified of
the proposal.

> As I've been out of the community for so long, I no longer have a
> sense of when things are merged.

To be honest, I am irritated at what looks like bulldozering through
with a proposal that has the clear implications of removing the current
lead developer from the project eventually, in particular since there
are no other imminent problems it currently purports to solve.  The
proposal arrived today and you want to have it accepted within hours.

I think that this is not a time frame where other developers as well as
users can be expected to make and voice a qualified decision.

-- 
David Kastrup

Issue 5739: Add makefile targets for formatting all C++ code (issue 565620043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

Reviewers: ,

Description:
https://sourceforge.net/p/testlilyissues/issues/5739/

These are not yet intended for routine use by contributors.  They are
meant to help explore the differences between astyle and clang-format.

Please review this at https://codereview.appspot.com/565620043/

Affected files (+48, -0 lines):
  M GNUmakefile.in
  M config.make.in
  M configure.ac


Index: GNUmakefile.in
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 
d63850fde6a4fb163f0b77c6c0abbae3accd3ac3..0d570c65456ea6342cd363795ba0bee7878cf972
 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -313,6 +313,50 @@ grand-replace:
PATH=$(buildscript-dir):$(PATH) $(buildscript-dir)/grand-replace
 
 
+
+# code formatting
+
+## TODO: This condition speeds up make when formatting targets are not
+## going to be run.  Explore alternatives (lazy init?).
+ifneq (,$(filter format%,$(MAKECMDGOALS)))
+
+CXX_STYLE_FILES := \
+   $(wildcard $(top-src-dir)/*/*/*[ch]) \
+   $(wildcard $(top-src-dir)/*/*.cc)
+# end list
+
+# Format updated source files using astyle.
+ASTYLE_STAMP:=$(top-build-dir)/.astyle-done
+.PHONY: format-all-astyle
+format-all-astyle: $(ASTYLE_STAMP)
+$(ASTYLE_STAMP): $(CXX_STYLE_FILES)
+#   format the source files that are newer than the timestamp file
+   $(call ly_progress,Making,$@,($(words $?) files))
+#   TODO: fixcc complains if more than 4 files are given
+   echo $? | xargs -n4 $(top-src-dir)/scripts/auxiliar/fixcc.py
+   touch $@
+
+# Format updated source files using clang-format.
+CLANG_FORMAT_STAMP:=$(top-build-dir)/.clang-format-done
+.PHONY: format-all-clang
+format-all-clang: $(CLANG_FORMAT_STAMP)
+$(CLANG_FORMAT_STAMP): $(CXX_STYLE_FILES)
+#   format the source files that are newer than the timestamp file
+   $(call ly_progress,Making,$@,($(words $?) files))
+   $(CLANG_FORMAT) -i $?
+   touch $@
+
+# Format updated source files using one of multiple approved tools,
+# depending on what is installed.
+.PHONY: format-all
+ifneq ($(CLANG_FORMAT),false)
+format-all: format-all-clang
+else
+format-all: format-all-astyle
+endif
+
+endif
+
 
 # testing
 
Index: config.make.in
diff --git a/config.make.in b/config.make.in
index 
8825c909e3fc0de699e5b952b69e1c183d436250..04debde0720a845c2e8847ca1f8dd5ded209fd8e
 100644
--- a/config.make.in
+++ b/config.make.in
@@ -107,6 +107,7 @@ AR = @AR@
 BASH = @BASH@
 BISON = @BISON@
 CC = @CC@
+CLANG_FORMAT = @CLANG_FORMAT@
 CONFIGSUFFIX = @CONFIGSUFFIX@
 CROSS = @cross_compiling@
 CXX = @CXX@
Index: configure.ac
diff --git a/configure.ac b/configure.ac
index 
72bd994740e85f2278ffc6c1368ce6ac0bdcaddd..a87c80339fdfb713d5d812649716c5f9398e5b36
 100644
--- a/configure.ac
+++ b/configure.ac
@@ -363,6 +363,9 @@ fi
 # perl for help2man and for mf2pt1.pl
 STEPMAKE_PERL(REQUIRED)
 
+# code formatting
+STEPMAKE_PROGS(CLANG_FORMAT, clang-format-9 clang-format, OPTIONAL, 9, 9)
+
 # tidy can be used to validate the HTML pages produced during
 # regression testing
 STEPMAKE_PATH_PROG(TIDY, tidy, OPTIONAL)

Re: New build:

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: 
Sent: Wednesday, February 05, 2020 3:50 PM
Subject: Re: New build:



"Phil Holmes"  writes:


The web site is now fairly up-to-date.  I say "fairly" because "news"
has not been updated.  I believe this is because the website is
actually built automatically from master, whereas I updated news in
stable/2.20.  I guess the simplest option is to cherry-pick my updates
to the news files into staging.  I remain a bit uncertain about git
(and fairly out of practice). Could someone (David?) skilled in the
art update staging from stable/2.20?


On the way.

--
David Kastrup



LGTM. Website now up-to-date.

--
Phil Holmes

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Mike Solomon  writes:

>> What does "implement" mean?
>
> Sorry, I wasn't clear. I meant merge the PR.

> Uh, words have meanings.  There would be no point of putting something
into our documentation that we are not going to follow through with.

By merging it, the idea would be that the first committee of 3 started acting 
as a CoC committee.

What are the blockers to making a decision about this patch? Does it need more 
discussion or more buy in? As I've been out of the community for so long, I no 
longer have a sense of when things are merged.

~Mike

Re: Documentation suggestions.

[Peter Toye]

Dear Michael,

That's very kind of you. When my life gets sorted out I may return to the fray. 
I've got a few comments below.

I don't have a Reitveld account so can't reply there. Should I get one?

I have another small patch for LR: Section 1.1.4 the first example needs the 
version number correcting to whatever the next publication references. The 
other uses of \version are OK.

Best regards,

Peter


-
Wednesday, February 5, 2020, 1:08:55 PM, you wrote:

> Hello Peter,


> Am 04.02.2020 um 10:44 schrieb Peter Toye:
>> I'm posting this here, as no-one on the devel list has answered, although 
>> most of the discussion went on in that list.
> I think that many developers spend their effort on core topics like the
> guile-2/3 transition,
> or improving the contribution process, etc. at the moment.
> I prepared a patch, mostly following your suggestions. Now every
> developer can discuss your suggestions
> during the formal code review procedure.

I thought that too.

> The review is here:
> http://codereview.appspot.com/579280043

> The tracker issue is:
> https://sourceforge.net/p/testlilyissues/issues/5738/
>> LM 1.2.1 Simple notation. Add a paragraph after the 1st music example:
>>
>> Note-names in all examples use the English or Dutch naming system 
>> (white piano keys are C-B).
> As Kieren pointed out it cannot be the English system (at least if
> alterations come into play),
> I think it is sufficient to mention the Dutch system.

I didn't give you a very good patch - I really should have said "Note-names in 
all examples in this section...". Later sections use alterations/accidentals 
freely, of course.

I'm slightly worried that new users who aren't Dutch will immediately be put 
off LilyPond by not understanding the very first real example, or thinking that 
they have to learn Dutch names for all the musical elements. Users of the Do-Si 
notation styles may like to know that they can use their native musical 
language.

>> LM 2.1.2 Pitches and key signatures. Subsection Pitch alterations. 3rd 
>> paragraph
>> (1)after 'alterations' add 'and note-names'.
>> (2) append:
>>
>> The default language for note-names and alterations is 
>> nederlands (Dutch).
>>
>> A question: is "alterations" a good word throughout this subsection? The 
>> normal English one is "accidentals", which is used in the Music Glossary 
>> reference.
> IMHO, alteration applys to the underlying
> process of "altering" a note,
> which is part of the input,
> "accidental" is the graphical sign that does
> show the alteration, hence
> rather part of the rendering.

You don't think it necessary to reference the default? Maybe that should be in 

Hmmm. I've never heard the word 'alteration' used in this context. If I refer 
(in English) to 'F sharp' I call the 'sharp' an accidental, whether it's 
printed or merely played/heard. 'Alter' can refer to any sort of change, not 
just semitone pitch adjustments. It might be an ottava sign, for instance. I 
also note that the corresponding section in NR 1.1.1 is titled 'Accidentals'. 
We should be consistent here.

I agree that accidentals aren't always alterations - they may be there as a 
courtesy to the player, or even prefixed to every note whether or not it is 
necessary.

>> 
>> NR 3.1.5 File Structure. Subsection Using variables. Add  a "Known Issues"  
>> subsection at end:
>>
>>
>> In addition to the normal convention for variable names [add 
>> reference to LM 2.4.1] variable names can include non-ASCII characters and 
>> non-adjacent single underscores and dashes. Any combination of characters is 
>> allowed if the variable name is enclosed in double quotation marks. In this 
>> case backslashes and double quotation marks need to be escaped with 
>> backslashes.

I mostly used David Kastrup's text here. I see that lemzwerg has objected on 
the grounds that "'Alphabetic characters' and 'non-ASCII characters' are not 
different sets but are overlapping".. I would point out that LM 2.4.1 uses the 
term 'alphabetic', presumably meaning [A-Z] and [a-z]. These are all ASCII 
characters. My text admits the use of single underscores and dashes, lemzwerg's 
does not. A reference manual shold be complete, while pointing out the 
difference between best practice (Alpha) and other forms of variable name.

I like the examples he gives, but should point out that 'HornIII' is composed 
entirely of ASCII characters. Maybe more useful than the made-up Greek would be 
a real example- try 'Теноры'

>> ---
>> NR 1.2.5  Bars. Sub section Bar and bar number checks. Add a "known issues" 
>> section at end:
>>
>> If MIDI output is selected and volta repeats are in place, the bar 
>> number check may fail. It is best to suppress MIDI output while checking bar 
>> numbers.

I see that Dan Eble has objected to this on the grounds that bar 

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Mike Solomon  writes:

>> What does "implement" mean?
>
> Sorry, I wasn't clear. I meant merge the PR.

Uh, words have meanings.  There would be no point of putting something
into our documentation that we are not going to follow through with.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

> What does "implement" mean?

Sorry, I wasn't clear. I meant merge the PR.

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Mike Solomon  writes:

> One procedural question: what are acceptance procedures for a PR like
> this? There is good debate and a variety of opinions, but at a certain
> point we will need to make a decision - do we implement the CoC or
> not?

What does "implement" mean?

> I doubt that any new arguments will emerge on either side.  David has
> made several good arguments against it,

I would not call them "good" as much as "personal".

> and while the points are valid, they don't outweigh IMO the potential
> for it to improve the problem of low contribution volume and a
> shrinking pool of developers. I'm also admittedly biased in that I
> don't feel comfortable contributing unless there is a code of conduct
> with clear steps for reporting violations and consequences for repeat
> offenders, so I'm probably not the best person to make the final call.
>
> ~Mike
>
>

-- 
David Kastrup

Re: [RFC] switch to GitLab / gitlab.com

[Dan Eble]

On Feb 5, 2020, at 10:09, Jonas Hahnfeld  wrote:
> 
> required to synchronize the review and the associated issue. I propose
> to start using GitLab hosted on gitlab.com [4] for all of this:
> Repository, Issues, and Merge Requests (MR) for reviews. It was
> evaluated 'C' in 2015 [5] and should be an 'acceptable hosting for a
> GNU package' [6].

Fine with me.  I don't expect to donate my time to make _any_ move happen, but 
I'd accept working with these tools to get my patches into LilyPond.  It could 
hardly be worse than the current combination.
— 
Dan

Re: Code of Conduct

[David Kastrup]

Trevor  writes:

> Dan Eble wrote 05/02/2020 14:25:26
> Subject: Re: Code of Conduct
>
>>On Feb 5, 2020, at 05:45, Han-Wen Nienhuys  wrote:
>>>
>>>  Having a CoC gives us a set of guidelines, a process and a set of
>>>  corrective actions to take to help keep things nice.
>>
>>I prefer the implicit good-neighbour agreement we have now.
> So do I! Definitely!
>
> It's remarkable how well it has worked and how free of animosity it
> has been.

There have been frictions over the years on both developer and user
lists and I removed myself from participating on the user list a number
of times over periods of probably about a month's length.  And it's not
longer than about a month ago that my wording of a reply that I spent
half an hour composing from manual entries and example code earned me
more the equivalent of a "fsck you" than "thank you".  So from my side I
cannot state in good conscience that there would be no leeway to
improve.  But that's not a matter where a committee could provide
reasonable help or relief.

Making the best of what we have available to our disposal is in the end
all we can hope to do, even though there are a lot of times I'd wish I'd
be able to do better.  As such I am grateful for people whose first
thought when the results are less than impressive is support and
mitigation rather than punishment.

-- 
David Kastrup

Re: [RFC] switch to GitLab / gitlab.com

[David Kastrup]

Jonas Hahnfeld  writes:

[Not repeating well-thought considerations]

> Closing thoughts
> 
>
> GitLab has a feature called 'Repository mirroring' [8], working in both
> directions. During the switching period, we could maintain Savannah as
> our main repository and let GitLab pull in changes from there. After a
> final cut, GitLab could instead be configured to push master and
> stable/* branches to Savannah.

It's worth stating that the large migration hurdle is actually saving as
much from tracker/review setup we have as possible.  Switching Git
repositories, in comparison, is a rather small hurdle.  We need to get
our ducks in a row regard the contributor documentation and scripts, but
otherwise that part is rather simple (famous last words).

> Links
> =
> 1: https://git.savannah.gnu.org/cgit/lilypond.git/
> 2: https://sourceforge.net/p/testlilyissues/issues/
> 3: https://codereview.appspot.com/
> 4: https://gitlab.com/explore
> 5: https://www.gnu.org/software/repo-criteria-evaluation.html
> 6: https://www.gnu.org/software/repo-criteria.html
> 7: https://docs.gitlab.com/ee/user/project/settings/import_export.html
> 8: 
> https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html
>

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

One procedural question: what are acceptance procedures for a PR like this? 
There is good debate and a variety of opinions, but at a certain point we will 
need to make a decision - do we implement the CoC or not? I doubt that any new 
arguments will emerge on either side.  David has made several good arguments 
against it, and while the points are valid, they don't outweigh IMO the 
potential for it to improve the problem of low contribution volume and a 
shrinking pool of developers. I'm also admittedly biased in that I don't feel 
comfortable contributing unless there is a code of conduct with clear steps for 
reporting violations and consequences for repeat offenders, so I'm probably not 
the best person to make the final call.

~Mike

Re[2]: Code of Conduct

[Trevor]

Dan Eble wrote 05/02/2020 14:25:26
Subject: Re: Code of Conduct


On Feb 5, 2020, at 05:45, Han-Wen Nienhuys  wrote:


 Having a CoC gives us a set of guidelines, a process and a set of
 corrective actions to take to help keep things nice.


I prefer the implicit good-neighbour agreement we have now.

So do I! Definitely!

It's remarkable how well it has worked and how free of animosity it has 
been.


Trevor

Re: New build:

[David Kastrup]

"Phil Holmes"  writes:

> The web site is now fairly up-to-date.  I say "fairly" because "news"
> has not been updated.  I believe this is because the website is
> actually built automatically from master, whereas I updated news in
> stable/2.20.  I guess the simplest option is to cherry-pick my updates
> to the news files into staging.  I remain a bit uncertain about git
> (and fairly out of practice). Could someone (David?) skilled in the
> art update staging from stable/2.20?

On the way.

-- 
David Kastrup

Re: New build:

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - From: "David Kastrup" 
> To: "Phil Holmes" 
> Cc: ; 
> Sent: Wednesday, February 05, 2020 3:05 PM
> Subject: Re: New build:
>
>
>> David Kastrup  writes:
>>
>>> "Phil Holmes"  writes:

 The build completed successfully, as did the upload, so anyone looking
 at the manuals on lilypond.org will see 19.84 information.  However,
 the website has not built, I think because VERSION in master has not
 been updated.  I've pushed an updated VERSION to staging, but my
 patchy refuses to run because I have a too -old version of Python.
 Python -V gives 2.7.6. Could someone:

 1.  Tell me a safe method for getting Python >3.5 on Ubuntu 14.04,
 please?
>>>
>>> No idea.  You have backports already enabled in your update sources?  In
>>> case it may be available from there?
>>>
>>> Should be checkable as "settings and ???" when calling
>>>
>>> sudo update-manager
>>>
 2.  Possibly run patchy-staging
>>>
>>> On its way.
>>
>> patchy-staging completed.
>>
>> -- David Kastrup
>>
>
> The web site is now fairly up-to-date.  I say "fairly" because "news"
> has not been updated.  I believe this is because the website is
> actually built automatically from master, whereas I updated news in
> stable/2.20.  I guess the simplest option is to cherry-pick my updates
> to the news files into staging.  I remain a bit uncertain about git
> (and fairly out of practice). Could someone (David?) skilled in the
> art update staging from stable/2.20?

Ah, ok.  I'll give it a hand.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Mike Solomon  writes:

> Mike Solomon  writes:
>
>> The preamble and intent is one thing; adding a corrective committee
>> with the authority to enact punishments based on anonymous reports
>> is another.  It implements hierarchies and institutions exerting
>> coercive power based on incomplete and secret information.  That is
>> inherently an entity offering an opportunity for "pulling strings".
>> I am not really a fan of constructs with a life and dynamics of
>> their own.
>
> It's a big responsibility. I think the way to do it is talk to
> successful committees (ie the Facebook Open Source CoC Committee) and
> learn how they've dealt with challenging situations.
>
> One example: in communities that are more gender balanced, I've heard
> of situations where a man starts writing inappropriate messages to a
> woman and she reports the messages to the CoC committee.  In this
> case, I think secrecy, hierarchy and coercive decision making power is
> important to preserve the dignity of all parties.  It also encourages
> people to come forward, which is much harder to do in the open.

Frankly, I have my doubts that "in case you encounter a problem with
acceptance of your demographic, here is a committee of three white men
you can complain to" will be the most successful pitch.

> I don't know of many communities with good gender balance that don’t
> have codes of conduct, probably for this reason.

Programming communities tend to be very lopsided.  That was different
the other way round when programming was considered low-pay work serving
mathematicians.  It's also at least less extreme outside of Western
cultures.  Personally, I find that disgraceful as a statement about
society, but the demographics in developer groups tend to reflect what
society does.  In the LilyPond user groups, one does see occasional
women with questions (judging from the names) and I don't recollect any
inappropriate or gender-isolating behavior in response.

> Ultimately, I think the benefits of secrecy, hierarchy and possible
> coercion in matters of conduct outweigh the negatives,

I think it depends on the necessity.  Do you have any examples of female
contributors or users that have been treated on LilyPond mailing lists
or other communication media in a manner where it would have been
reasonable to assume that they would have wanted to be able to file a
complaint?

> although I agree with you that secrecy and hierarchy should be the
> exception and not the rule. Most communication should be in the open
> and hierarchy free.
>
> Thanks,
> ~Mike

-- 
David Kastrup

Re: New build:

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: ; 
Sent: Wednesday, February 05, 2020 3:05 PM
Subject: Re: New build:



David Kastrup  writes:


"Phil Holmes"  writes:


The build completed successfully, as did the upload, so anyone looking
at the manuals on lilypond.org will see 19.84 information.  However,
the website has not built, I think because VERSION in master has not
been updated.  I've pushed an updated VERSION to staging, but my
patchy refuses to run because I have a too -old version of Python.
Python -V gives 2.7.6. Could someone:

1.  Tell me a safe method for getting Python >3.5 on Ubuntu 14.04, 
please?


No idea.  You have backports already enabled in your update sources?  In
case it may be available from there?

Should be checkable as "settings and ???" when calling

sudo update-manager


2.  Possibly run patchy-staging


On its way.


patchy-staging completed.

--
David Kastrup



The web site is now fairly up-to-date.  I say "fairly" because "news" has 
not been updated.  I believe this is because the website is actually built 
automatically from master, whereas I updated news in stable/2.20.  I guess 
the simplest option is to cherry-pick my updates to the news files into 
staging.  I remain a bit uncertain about git (and fairly out of practice). 
Could someone (David?) skilled in the art update staging from stable/2.20?


Thanks again.

--
Phil Holmes 

Re: development process

[David Kastrup]

Kevin Barry  writes:

> I don't know if lurkers' opinions count, but on the subject of potential
> replacements for Savannah/Sourceforge: I am part of a team that administer
> both Gerrit and Gitlab in-house deployments. If choosing between them I
> would advocate for Gitlab because it includes issue tracking and CI/CD so
> perhaps all work can go through one place and contributors/maintainers
> would not need to have accounts for multiple apps/systems. Gerrit is a good
> code review tool, but for various reasons that may be our own fault, it is
> deeply unpopular where I work.

Ok, that's giving us one point of reference.

> I am sadly not quite up to the task of developing the codebase (maybe one
> day), but I can help with systems/operational things if wanted.

Our last infrastructure move suffered heavily from the people tasked
with it not being acquainted and/or comfortable with the
systems/operational things at hand.

It was sort of a painful lesson, but at the current point of time it
would appear that self-hosting an instance rather than having to rely on
a tentatively "free" offering might be too optimistic for a project of
LilyPond's size compared to the available manpower and knowledge.

And Savannah, the GNU infrastructure, does not really have the sysadmin
power to be part of a helpful solution either, even though we can host
the naked Git repository there (and already do so).

> (I don't have a view on the bigger discussion about process - the
> change most likely to help me to contribute would be mentorship rather
> than any process change).

-- 
David Kastrup

RE: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Mike Solomon  writes:

> The preamble and intent is one thing; adding a corrective committee with the 
> authority to enact punishments based on anonymous reports is another.  It 
> implements hierarchies and institutions exerting coercive power based on 
> incomplete and secret information.  That is inherently an entity offering an 
> opportunity for "pulling strings".  I am not really a fan of constructs with 
> a life and dynamics of their own.

It's a big responsibility. I think the way to do it is talk to successful 
committees (ie the Facebook Open Source CoC Committee) and learn how they've 
dealt with challenging situations.

One example: in communities that are more gender balanced, I've heard of 
situations where a man starts writing inappropriate messages to a woman and she 
reports the messages to the CoC committee.  In this case, I think secrecy, 
hierarchy and coercive decision making power is important to preserve the 
dignity of all parties.  It also encourages people to come forward, which is 
much harder to do in the open.

I don't know of many communities with good gender balance that don’t have codes 
of conduct, probably for this reason.  Ultimately, I think the benefits of 
secrecy, hierarchy and possible coercion in matters of conduct outweigh the 
negatives, although I agree with you that secrecy and hierarchy should be the 
exception and not the rule. Most communication should be in the open and 
hierarchy free.

Thanks,
~Mike

Re: development process

[Kieren MacMillan]

Hi all,

> I don't know if lurkers' opinions count

I hope so, because I’m about to give another one…  ;)

> Gerrit is a good code review tool, but for various reasons
> that may be our own fault, it is deeply unpopular where I work.

I know very few of these tools — my deepest version control experience was with 
CVS, and that was nearly 20 years ago — but seeing these discussions, it seems 
to me very unlikely that a truly democratic process will result in a toolchain 
that everyone likes working with (though I’m hopeful that it can at least 
result in a toolchain that everyone *will* work with).

> (I don't have a view on the bigger discussion about process - the change
> most likely to help me to contribute would be mentorship rather than any
> process change).

+1

I have many projects (hopefully leading to patches!) on the go, ready to bring 
to a mentor once the toolchain and process dust settles.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

[RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

(Note: I wrote this in ~1 hour, so some details are not thought through
yet. I rather want this to serve as an example of a concrete proposal
to change one thing at a time.)

What this proposal is about
===

Right now, LilyPond's source code is hosted on Savannah [1], our issues
are tracked on SourceForge [2] and we review patches on Rietveld [3].
There is no synchronization between the systems and a contributor is
required to synchronize the review and the associated issue. I propose
to start using GitLab hosted on gitlab.com [4] for all of this:
Repository, Issues, and Merge Requests (MR) for reviews. It was
evaluated 'C' in 2015 [5] and should be an 'acceptable hosting for a
GNU package' [6].

Using the managed installation on gitlab.com has the advantage that we
don't need to maintain it. Also future contributors might already have
an account and can start submitting MRs as they are used to. It should
make bug reporting more straight-forward too, with the issues right
next to the repository.

If deemed necessary, it should be possible to transfer existing issues
from SourceForge via GitLab's API. For the future, we can use exports
from GitLab [7] as backups and rely on them should we ever wish to
switch tools.

What this is NOT about
==

I'm NOT proposing any change to the processes used right now. In
particular:
 * Review stays mandatory, but instead of Rietveld you push to a branch
(or a fork if you like) and open a MR.
 * The Patch meister keeps on testing (manually for now; CI could be a
future step) and posts the results in the MR.
 * We still have countdowns, but instead of SourceForge we use labels
in GitLab to track the status.
 * After countdown, commits are pushed to staging; patchy-staging
transfers them to master.

Alternatives considered
===

One option would be self-hosting GitLab and not using gitlab.com. This
comes with the disadvantage that somebody has to maintain the server.
From my personal experience, this takes a large amount of time and
dedication because GitLab is very complex to update.

 * GNU Savannah: could handle issues, but no reviews
 * GitHub: bought by Microsoft and proprietary, rated F /
'Unacceptable' [6]
 * Gitea: only self-hosted as far as I know, still relatively new
 * Gerrit: only a review tool, so issues and source code hosting need
additional tools

Closing thoughts


GitLab has a feature called 'Repository mirroring' [8], working in both
directions. During the switching period, we could maintain Savannah as
our main repository and let GitLab pull in changes from there. After a
final cut, GitLab could instead be configured to push master and
stable/* branches to Savannah.

Links
=
1: https://git.savannah.gnu.org/cgit/lilypond.git/
2: https://sourceforge.net/p/testlilyissues/issues/
3: https://codereview.appspot.com/
4: https://gitlab.com/explore
5: https://www.gnu.org/software/repo-criteria-evaluation.html
6: https://www.gnu.org/software/repo-criteria.html
7: https://docs.gitlab.com/ee/user/project/settings/import_export.html
8: https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html


signature.asc
Description: This is a digitally signed message part

Re: development process

[Kevin Barry]

I don't know if lurkers' opinions count, but on the subject of potential
replacements for Savannah/Sourceforge: I am part of a team that administer
both Gerrit and Gitlab in-house deployments. If choosing between them I
would advocate for Gitlab because it includes issue tracking and CI/CD so
perhaps all work can go through one place and contributors/maintainers
would not need to have accounts for multiple apps/systems. Gerrit is a good
code review tool, but for various reasons that may be our own fault, it is
deeply unpopular where I work.

I am sadly not quite up to the task of developing the codebase (maybe one
day), but I can help with systems/operational things if wanted.

(I don't have a view on the bigger discussion about process - the change
most likely to help me to contribute would be mentorship rather than any
process change).

Re: New build:

[David Kastrup]

David Kastrup  writes:

> "Phil Holmes"  writes:
>>
>> The build completed successfully, as did the upload, so anyone looking
>> at the manuals on lilypond.org will see 19.84 information.  However,
>> the website has not built, I think because VERSION in master has not
>> been updated.  I've pushed an updated VERSION to staging, but my
>> patchy refuses to run because I have a too -old version of Python.
>> Python -V gives 2.7.6. Could someone:
>>
>> 1.  Tell me a safe method for getting Python >3.5 on Ubuntu 14.04, please?
>
> No idea.  You have backports already enabled in your update sources?  In
> case it may be available from there?
>
> Should be checkable as "settings and ???" when calling
>
> sudo update-manager
>
>> 2.  Possibly run patchy-staging
>
> On its way.

patchy-staging completed.

-- 
David Kastrup

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[lemzwerg--- via Discussions on LilyPond development]

A nit.


https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely#newcode464
Documentation/notation/input.itely:464: escaped with backslashes.
This is confusing.  'Alphabetic characters' and 'non-ASCII characters'
are not different sets but are overlapping.  What about

  The name of a variable should not contain (ASCII) numbers,
  underscores, dashes, or space characters.  All other
  characters Unicode provides are allowed, for example Latin,
  Greek, or Chinese.  In other words, variable names like
  @code{HornIII} or @code{αβγXII} work.

  Any combination of characters is allowed if the variable name
  is enclosed in double quotation marks.  In this case
  backslashes and double quotation marks need to be escaped with
  backslashes (not that you actually should use them).
  Examples: @code{"foo bar"}, @code{"a-b-c"}, @code{"Horn 3"}.

https://codereview.appspot.com/579280043/

RE: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Janek Warchoł  writes:

> Hi,
>
> śr., 5 lut 2020, 00:34 użytkownik  napisał:
>
>> What problem are we trying to solve here?
>>
>
> In short, it's been found (I think Mike will be able to give you 
> specific
> examples) that having code of conduct encourages contributions from 
> newcomers.

> I rather think that a friendly atmosphere encourages contributions from 
> newcomers.  Whether an upfront requirement to commit to a set of rules with 
> an enforcement team is perceived as a guarantee of a friendly atmosphere is 
> debatable.

I personally would feel more comfortable if there were a code of conduct, and I 
know within my company one employee will not attend a conference or participate 
in a project unless there is a code of conduct.  I don't have any hard stats to 
prove this, but have a gut feeling that a code of conduct opens more doors than 
it closes.

> So in light of my personal experiences with this kind of backroom channel 
> (and it's worth noting that even the cited Linux developer list removed the 
> corrective measures part from the CoC they are using), I would very much like 
> to see some more imminent reason of why LilyPond would stand to benefit from 
> adopting a code and accepting a corrective committee that has basically 
> proposed itself rather than being the result of a list-wide election and 
> where just one member has been a permanent fixture on the lists for a longer 
> amount of time at this moment.

A list-wide election is a good idea.

At the Salzburg meetup, one common thing a lot of people brought up was a 
slow-down in development and a shrinking pool of contributors.  IMO we should 
do several experiments to fix this. The CoC I proposed is used in over 40,000 
projects including many of the most active and diverse open source projects on 
github, so it seems like a reasonable experiment. If it proves to be a dud, we 
can get rid of it.

~Mike

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Another remark:

Mike Solomon  writes:

> At the Salzburg meetup, one common thing a lot of people brought up
> was a slow-down in development and a shrinking pool of contributors.
> IMO we should do several experiments to fix this. The CoC I proposed
> is used in over 40,000 projects including many of the most active and
> diverse open source projects on github, so it seems like a reasonable
> experiment.

I think that may be confusing cause and effect.  I consider it more
likely that people saw a necessity of formalising relations and
communication _because_ they were amongst the most active and diverse
groups than the other way round.

> If it proves to be a dud, we can get rid of it.

I'd prefer to do it the other way round: if we can to a reasonable
degree agree that our communication has become a dud, that may be
incentive to get a hold of it.

Independent of promising corrective measures, I would not object to
quoting the GNU kind communication guidelines on our web pages and
asking contributors to give them a good thought.

Quoting relevant parts where people's communication are in obvious need
of improvement are also appropriate.

What I find less effective is just name-dropping of either CoC or the
GNU guidelines without referencing a particular passage.  Probably more
so with the latter since they do not contain an inherent threat.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Mike Solomon  writes:

> Janek Warchoł  writes:
>
>> Hi,
>>
>> śr., 5 lut 2020, 00:34 użytkownik  napisał:
>>
>>> What problem are we trying to solve here?
>>>
>>
>> In short, it's been found (I think Mike will be able to give you 
>> specific
>> examples) that having code of conduct encourages contributions from 
>> newcomers.
>
>> I rather think that a friendly atmosphere encourages contributions
>> from newcomers.  Whether an upfront requirement to commit to a set
>> of rules with an enforcement team is perceived as a guarantee of a
>> friendly atmosphere is debatable.
>
> I personally would feel more comfortable if there were a code of
> conduct, and I know within my company one employee will not attend a
> conference or participate in a project unless there is a code of
> conduct.  I don't have any hard stats to prove this, but have a gut
> feeling that a code of conduct opens more doors than it closes.
>
>> So in light of my personal experiences with this kind of backroom
>> channel (and it's worth noting that even the cited Linux developer
>> list removed the corrective measures part from the CoC they are
>> using), I would very much like to see some more imminent reason of
>> why LilyPond would stand to benefit from adopting a code and
>> accepting a corrective committee that has basically proposed itself
>> rather than being the result of a list-wide election and where just
>> one member has been a permanent fixture on the lists for a longer
>> amount of time at this moment.
>
> A list-wide election is a good idea.
>
> At the Salzburg meetup, one common thing a lot of people brought up
> was a slow-down in development and a shrinking pool of contributors.
> IMO we should do several experiments to fix this. The CoC I proposed
> is used in over 40,000 projects including many of the most active and
> diverse open source projects on github, so it seems like a reasonable
> experiment. If it proves to be a dud, we can get rid of it.

The preamble and intent is one thing; adding a corrective committee with
the authority to enact punishments based on anonymous reports is
another.  It implements hierarchies and institutions exerting coercive
power based on incomplete and secret information.  That is inherently an
entity offering an opportunity for "pulling strings".  I am not really a
fan of constructs with a life and dynamics of their own.

-- 
David Kastrup

Re: Code of Conduct

[Dan Eble]

On Feb 5, 2020, at 05:45, Han-Wen Nienhuys  wrote:
> 
> Having a CoC gives us a set of guidelines, a process and a set of
> corrective actions to take to help keep things nice.

I prefer the implicit good-neighbour agreement we have now.
—
Dan

Re: New build:

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - From: "David Kastrup" 
> To: "Phil Holmes" 
> Cc: "Jonas Hahnfeld" ; "Dan Eble" ;
> "Masamichi Hosoda" ; ; 
> 
> Sent: Tuesday, February 04, 2020 5:34 PM
> Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in
> MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)
>
>
>> "Phil Holmes"  writes:
>>
>>> - Original Message - From: "David Kastrup" 
 Wow.  Ok, maybe I'll just apply this patch then (though I'll at
 least
 remove the conditioning on Apple here as the problem is rather likely
 platform independent) and Phil may have another round.
 -- David Kastrup
>>>
>>>
>>> Will kick this off again tomorrow.
>>
>> Thanks!
>>
>> -- David Kastrup
>
>
> The build completed successfully, as did the upload, so anyone looking
> at the manuals on lilypond.org will see 19.84 information.  However,
> the website has not built, I think because VERSION in master has not
> been updated.  I've pushed an updated VERSION to staging, but my
> patchy refuses to run because I have a too -old version of Python.
> Python -V gives 2.7.6. Could someone:
>
> 1.  Tell me a safe method for getting Python >3.5 on Ubuntu 14.04, please?

No idea.  You have backports already enabled in your update sources?  In
case it may be available from there?

Should be checkable as "settings and ???" when calling

sudo update-manager

> 2.  Possibly run patchy-staging

On its way.

-- 
David Kastrup

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely#newcode3325
Documentation/notation/rhythms.itely:3325: bar number check may fail. 
It is best to suppress MIDI output
No.  Bar number checks are ignored by default when processing MIDI.  See
https://sourceforge.net/p/testlilyissues/issues/5624/ .

https://codereview.appspot.com/579280043/

New build: was:Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: "Jonas Hahnfeld" ; "Dan Eble" ; 
"Masamichi Hosoda" ; ; 


Sent: Tuesday, February 04, 2020 5:34 PM
Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW 
libraries (issue 577450043 by thomasmorle...@gmail.com)




"Phil Holmes"  writes:


- Original Message - From: "David Kastrup" 

Wow.  Ok, maybe I'll just apply this patch then (though I'll at
least
remove the conditioning on Apple here as the problem is rather likely
platform independent) and Phil may have another round.
--
David Kastrup



Will kick this off again tomorrow.


Thanks!

--
David Kastrup



The build completed successfully, as did the upload, so anyone looking at 
the manuals on lilypond.org will see 19.84 information.  However, the 
website has not built, I think because VERSION in master has not been 
updated.  I've pushed an updated VERSION to staging, but my patchy refuses 
to run because I have a too -old version of Python.  Python -V gives 2.7.6. 
Could someone:


1.  Tell me a safe method for getting Python >3.5 on Ubuntu 14.04, please?
2.  Possibly run patchy-staging

Thanks

--
Phil Holmes 

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[David Kastrup]

Dan Eble  writes:

> On Feb 5, 2020, at 07:59, jonas.hahnf...@gmail.com wrote:
>> 
>> and it seems stable, but I have yet to build a theory why OS thread
>> migration actually improves performance…
>
> Educated guess: The core gets too hot.  The OS is not allowed to move
> the thread to a cooler core, so it throttles the clock rate instead.

Heat dependent throttling would explain the rather drastic variation in
performance since it acts with large latencies.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[David Kastrup]

Janek Warchoł  writes:

> Hi,
>
> śr., 5 lut 2020, 00:34 użytkownik  napisał:
>
>> What problem are we trying to solve here?
>>
>
> In short, it's been found (I think Mike will be able to give you specific
> examples) that having code of conduct encourages contributions from
> newcomers.

I rather think that a friendly atmosphere encourages contributions from
newcomers.  Whether an upfront requirement to commit to a set of rules
with an enforcement team is perceived as a guarantee of a friendly
atmosphere is debatable.

So this issue would seem more pressing if there is evidence of people
acting in a way on the LilyPond lists denying people the opportunity to
contribute in a generally friendly atmosphere.

If that is not the case, the proposed solution involves censure and
eventual removement by a team of 3 enforcement officers.  Now of the
proposed team, two have already expressed personal issues with the way I
am conversing with the list, so given the generally very welcoming
atmosphere in the LilyPond lists, the principal impact to be expected on
LilyPond development appears to have an official body entitled to
censure my behavior and eventually, out of a sense of duty, remove me.

I have had this kind of backroom diplomacy remove me from one choir
after almost a year of intense work (I am an asset as a good sight
reader) before the first concert I could have participated in, and I
quit another choir I had worked hard for for five years after getting
censured by a choir committee after I had publicly answered a question
about whether a singing engagement at a choir member's birthday
celebration or else (things I participated in as a rule but would not be
foolish enough to ask for myself) should also involve a more tangible
present from the general choir funds.

I quit that choir since my personal and communication skills do not
allow me to take corrective action without actually communicating to the
offended party, and thus being censured via an official anonymous
complaint channel gave me no option of compensating for my well-known
deficiencies, and getting referred to via channels intended for
denunciation was not my idea of being part of a community.

Since judging from my personal past, the foreseeable impact on my
personal ability to keep participating as a community member given such
a mechanism will be high, the question is how much of a benefit is to be
expected for others from having a formalized committee where everyone,
on pain of getting expulsed themselves, is only doing their duty.

Now it is not that hard, given obvious public backing, to get me off a
list.  Andy Wingo has banned me from participating on the Guile
developer list, and I have pretty much obeyed that ban on the spot (with
at most a few replies a year creeping through when I followed
conversations and inadvertantly replied) even though it was not enacted
with technical measures.

The general stance of the GNU project on its internal lists is to rely
more on education and admonishment than official committees, censure,
and exclusion.

It can be read at
.  This document
is not focused on enforcement: instead it is a rationale for people with
problematic communication about why and how they could try to improve.

That is assuming, of course, that people are not recklessly engaging in
unwelcoming behavior: for open-and-shut cases, it tends to be within the
authority of a basic list administrator to take action.  This has
happened on LilyPond lists I think, but very rarely so.  The list
administrator doing duty here is not as much affiliated with LilyPond as
being a volunteer of GNU.  I think.  It's embarrassing that I don't even
know for sure, but that's the way things turn out that just work.

So in light of my personal experiences with this kind of backroom
channel (and it's worth noting that even the cited Linux developer list
removed the corrective measures part from the CoC they are using), I
would very much like to see some more imminent reason of why LilyPond
would stand to benefit from adopting a code and accepting a corrective
committee that has basically proposed itself rather than being the
result of a list-wide election and where just one member has been a
permanent fixture on the lists for a longer amount of time at this
moment.

-- 
David Kastrup

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[Dan Eble]

On Feb 5, 2020, at 07:59, jonas.hahnf...@gmail.com wrote:
> 
> and it seems stable, but I have yet to build a theory why OS thread
> migration actually improves performance…

Educated guess:  The core gets too hot.  The OS is not allowed to move the 
thread to a cooler core, so it throttles the clock rate instead.
— 
Dan

Re: development process

[Dan Eble]

On Feb 5, 2020, at 06:57, David Kastrup  wrote:
> 
> Our current process is awkward technically, not because of the roles its
> human players assume.

+1(000)

For a long time, the LilyPond project has needed these:

  1. more and better automation to reduce the load on the (amazingly
 perseverant) patch tester and lower the bar for others to help
  2. better-integrated bug tracking, code review, and source control
  3. a cross-platform build that is more maintainable, faster, and
 more frequently run

And these are the proposals I've been seeing:

  1. reduced opportunity for review; reduced emphasis on consensus
  2. new roles
  3. a code of conduct
  4. a straw man or two (coming from a lack of familiarity with the
 status quo)
  5. better-integrated bug tracking, code review, and source control

There is some common ground here, but it also comes across in part as trying to 
fix what's not broken.  Perhaps if you would first improve the tools and 
testing, people's confidence in them would grow and they would then be more 
willing to reduce the level of scrutiny on patches.
-- 
Dan

Re: Documentation suggestions.

[Michael Käppler]

Hello Peter,


Am 04.02.2020 um 10:44 schrieb Peter Toye:

I'm posting this here, as no-one on the devel list has answered, although most 
of the discussion went on in that list.

I think that many developers spend their effort on core topics like the
guile-2/3 transition,
or improving the contribution process, etc. at the moment.
I prepared a patch, mostly following your suggestions. Now every
developer can discuss your suggestions
during the formal code review procedure.

The review is here:
http://codereview.appspot.com/579280043

The tracker issue is:
https://sourceforge.net/p/testlilyissues/issues/5738/

LM 1.2.1 Simple notation. Add a paragraph after the 1st music example:

Note-names in all examples use the English or Dutch naming system 
(white piano keys are C-B).

As Kieren pointed out it cannot be the English system (at least if
alterations come into play),
I think it is sufficient to mention the Dutch system.

LM 2.1.2 Pitches and key signatures. Subsection Pitch alterations. 3rd paragraph
(1)after 'alterations' add 'and note-names'.
(2) append:

The default language for note-names and alterations is 
nederlands (Dutch).

A question: is "alterations" a good word throughout this subsection? The normal English 
one is "accidentals", which is used in the Music Glossary reference.

IMHO, alteration applys to the underlying process of "altering" a note,
which is part of the input,
"accidental" is the graphical sign that does show the alteration, hence
rather part of the rendering.


NR 3.1.5 File Structure. Subsection Using variables. Add  a "Known Issues"  
subsection at end:


In addition to the normal convention for variable names [add reference 
to LM 2.4.1] variable names can include non-ASCII characters and non-adjacent 
single underscores and dashes. Any combination of characters is allowed if the 
variable name is enclosed in double quotation marks. In this case backslashes 
and double quotation marks need to be escaped with backslashes.
---
NR 1.2.5  Bars. Sub section Bar and bar number checks. Add a "known issues" 
section at end:

If MIDI output is selected and volta repeats are in place, the bar 
number check may fail. It is best to suppress MIDI output while checking bar 
numbers.
--
NR 3.3.2 Different editions from one source. Subsection Using tags. Add before paragraph 
3 ("The arguments..."):

\tag, \keepWithTag and \removeWithTag are music functions which take a 
music expression as their second argument. Thus they cannot be used to filter 
items such as  \book or \score blocks.
--
NR 3.2.1 Creating titles headers and footers. Subsection Default layout of 
headers and footers. Rename to:

Default layout of page headers and footers

and index it as "page headers", "page footers", "headers, page", "footers, 
page".
Possibly also promote it to a 3rd-level section? It doesn't have anything in 
common with the previous two subsections.

Added the indices, but left the title because changing it would have
involved checking and fixing many crossreferences in other
sections / manuals / translations.

Regards and thanks for your work,
Michael


===8<===End of original message text===
___
bug-lilypond mailing list
bug-lilyp...@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[michael . kaeppler--- via Discussions on LilyPond development]

Reviewers: ,

Description:
Doc: Some miscellaneous suggestions from Peter Toye

Peter Toye suggested some additions/corrections to the
manuals a while ago in

https://lists.gnu.org/archive/html/lilypond-devel/2019-12/msg00191.html

and

https://lists.gnu.org/archive/html/bug-lilypond/2020-02/msg00010.html

He does not have the time to create a patch, so I prepared one for
him, mostly following his suggestions.
Sorry for the ambigous patch description.

Please review this at https://codereview.appspot.com/579280043/

Affected files (+28, -5 lines):
  M Documentation/learning/common-notation.itely
  M Documentation/learning/tutorial.itely
  M Documentation/notation/input.itely
  M Documentation/notation/rhythms.itely


Index: Documentation/learning/common-notation.itely
diff --git a/Documentation/learning/common-notation.itely 
b/Documentation/learning/common-notation.itely
index 
dec1677eb91796ce5330b0eebdafdac3298d9a83..39bf2f000e6ea7bec9ec511d9182b83eec714c31
 100644
--- a/Documentation/learning/common-notation.itely
+++ b/Documentation/learning/common-notation.itely
@@ -157,8 +157,9 @@ and a @notation{flat} pitch by adding @code{es}.  As you 
might
 expect, a @notation{double sharp} or @notation{double flat} is
 made by adding @code{isis} or @code{eses}.  This syntax is derived
 from note naming conventions in Nordic and Germanic languages,
-like German and Dutch.  To use other names for
-@notation{alterations}, see @ruser{Note names in other languages}.
+like German and Dutch.  To use other naming schemes for
+@notation{note names} and @notation{alterations},
+see @ruser{Note names in other languages}.
 
 @lilypond[verbatim,quote]
 \relative { cis''4 ees fisis, aeses }
@@ -1331,6 +1332,7 @@ cello = \new Staff {
 
 @noindent
 By convention, variable names consist of alphabetic characters only.
+For detailed information, see @ruser{File structure}.
 
 Variables must be defined @emph{before} the main music
 expression, but may be used as many times as required anywhere after
Index: Documentation/learning/tutorial.itely
diff --git a/Documentation/learning/tutorial.itely 
b/Documentation/learning/tutorial.itely
index 
27084f32eab12e95ac29cef38e2cda32ea92edcc..8de0c99a979119f2712052e0c4deda38697b8d3a
 100644
--- a/Documentation/learning/tutorial.itely
+++ b/Documentation/learning/tutorial.itely
@@ -213,7 +213,11 @@ Music Glossary: @rglos{pitch}, @rglos{interval},
 @rglos{scale}, @rglos{middle C}, @rglos{octave},
 @rglos{accidental}.
 
-LilyPond uses lower-case letters for pitches.  The letters
+LilyPond uses lower-case letters for pitches.
+The default note names are taken from the Dutch
+naming system (white piano keys are c-b).
+These note names are used in all following examples.
+The letters
 @code{c} through@tie{}@code{b} denote pitches in the
 @q{small octave} below @notation{middle C}.  Added @code{'}
 or@tie{}@code{,} suffixes indicate higher or lower octaves.
Index: Documentation/notation/input.itely
diff --git a/Documentation/notation/input.itely 
b/Documentation/notation/input.itely
index 
67c4fa3cbb3fab3674c8dbb7463240e3600a5e77..f0e906041c6ec9a252d89da2540017ea4147d500
 100644
--- a/Documentation/notation/input.itely
+++ b/Documentation/notation/input.itely
@@ -456,7 +456,12 @@ foo = @{ c4 d e d @}
 
 This can be used later on in the file by entering @code{\foo}.  The
 name of a variable should have alphabetic characters only; no
-numbers, underscores or dashes.
+numbers, underscores or dashes.  In addition to this convention,
+variable names can include non-ASCII characters and non-adjacent
+single underscores and dashes. Any combination of characters is
+allowed if the variable name is enclosed in double quotation marks.
+In this case backslashes and double quotation marks need to be
+escaped with backslashes.
 
 @end itemize
 
@@ -863,6 +868,11 @@ Installed Files:
 @node Default layout of headers and footers
 @unnumberedsubsubsec Default layout of headers and footers
 
+@cindex page headers
+@cindex page footers
+@cindex headers, page
+@cindex footers, page
+
 @emph{Headers} and @emph{footers} are lines of text appearing at
 the top and bottom of pages, separate from the main text of a book.
 They are controlled by the following @code{\paper} variables:
@@ -2243,7 +2253,9 @@ numbers, underscores, or dashes) which cannot be confused 
with notes,
 the @code{#'} may be omitted and, as a shorthand, a list of symbols
 can use the dot separator: i.e., @code{\tag #'(violinI violinII)} can
 be written @code{\tag violinI.violinII}.  The same applies to
-@code{\keepWithTag} and @code{\removeWithTag}.
+@code{\keepWithTag} and @code{\removeWithTag}.  All tagging commands
+cannot be used to filter items that are not music expressions, such as
+@code{\book} or @code{\score} blocks.
 
 In the following example, we see two versions of a piece of music,
 one showing trills with the usual notation, and one with trills
Index: Documentation/notation/rhythms.itely
diff --git a/Documentation/notation/rhythms.itely 

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

[jonas . hahnfeld]

Some more numbers: I took guile22-experiment and removed the following:
 * GC_set_free_space_divisor,
 * GC_INITIAL_HEAP_SIZE=40M
 * heap growing in Score_engraver

This gives me: ~2m30s (although I saw one run in 1m55s?!?)
GC_INITIAL_HEAP_SIZE=40M: ~2m10s (one run in 1m40s)
GC_FREE_SPACE_DIVISOR=1: very diverse - from ~1m10s (2 executions) to
~2m40s (3 executions)
GC_NPROCS=1: from ~1m45s to ~2m10s

This variation makes any statement about performance impractical. I
tried
taskset -c 2 + GC_NPROCS=1: ~2m10s
and it seems stable, but I have yet to build a theory why OS thread
migration actually improves performance...

Han-Wen, did you see similar variations in your experiments?

https://codereview.appspot.com/561390043/

Re: Doc: Correct and extend infos about LilyDev setup (issue 561360043 by michael.kaepp...@googlemail.com)

[Federico Bruni]

Il giorno sab 1 feb 2020 alle ore 00:17 Michael Käppler 
ha scritto:

> Am 30.01.2020 um 14:17 schrieb fedel...@gmail.com:
> >
> https://codereview.appspot.com/561360043/diff/565550050/Documentation/contributor/quick-start.itexi
> > File Documentation/contributor/quick-start.itexi (right):
> >
> >
> https://codereview.appspot.com/561360043/diff/565550050/Documentation/contributor/quick-start.itexi#newcode208
> > Documentation/contributor/quick-start.itexi:208: sufficient to choose
> > number@tie{}71 (Generic, 105 keys).  After that,
> > It seems it's not necessarily number 71. I would remove the number.
> > keyboards are sorted alphabetically so "Generic, 105 keys" is enough.
> Weird that this does show up differently. Yes, I will change this.
> >
> > Here's what I see:
> >
> > 65. Generic 101-key PC
> > 66. Generic 102-key (Intl) PC
> > 67. Generic 104-key PC
> > 68. Generic 105-key (Intl) PC
> >
> > I've tried 68 but didn't seem to work. I had to go to the GUI settings
> > for the layout, disable system setting and remove the english from the
> > list, then adding new layouts worked fine. (Probably a bug in Debian or
> > XFCE? Honestly, I don't have time nor will to investigate.)
> I cannot reproduce this. I used the v2 release you prepared, loaded
> it into VirtualBox 6.0.12, Host Windows 10.
> After dpkg-reconfigure keyboard-configuration, using number 68 as
> keyboard type and rebooting
> everything works fine.
> What did not work?
>

A lot of keys are not working correctly.
Nevermind, I never use the virtual machine. Containers are way better for
me.

Re: development process

[David Kastrup]

Thomas Morley  writes:

> Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup :
>>
>> Han-Wen Nienhuys  writes:
>>
>> >Rietveld and my local commits are not linked. If I change my commits, I
>> >update my commit message. I have to copy those changes out to Rietveld 
>> > by
>> >hand, and it took me quite a while to find the right button (“edit 
>> > issue”,
>> >somewhere in the corner).
>>
>> Then you have set it up incompletely or use it wrong.
>
> David, I disagree. As far as I can tell git-cl does not update
> commit-_messages_ on Rietveld.

After rereading what Han-Wen wrote more carefully, I have to agree that
he was right.  I thought this was about followup patches, but indeed the
commit message is not changed.

> Or I have an incomplete setup myself.

No, I was wrong and reading too sloppily.  Han-Wen is certainly correct
about that point.  But then I don't think anyone was really overly
defending our current toolset.

>> >The whole constellation of tools and processes (bug tracker for managing
>> >patch review, patch testing that seems to involve humans, Rietveld for
>> >patches, countdown, then push to staging) is odd and different from
>> >everything else. For contributing, you need to be very passionate about
>> >music typography, because otherwise, you won’t have the energy to 
>> > invest in
>> >how the process works.
>
> Yes, I took that route, fighting my my way through it.

I would think that the highest hurdle for dedicated testers is a working
development environment.

> Per aspera ad astra...

Well, I agree with Han-Wen that lowering the barrier of entrance is a
good idea.  When I started, VMs were quite unusual.  That has changed,
so maybe the highest hurdles have shifted a bit.

> As already said frequently, our current method is suboptimal.
> Afair, it was implemented because of the small amount of developers,
> most of them with limited time.
> As one example: the countdown-delay gave more of them the chance to
> look at proposed patches...
> Other problems: sourceforge is not the best as well, git-cl buggy etc
>
> Han-Wen, I do understand that current setup slows you down and annoys
> you and why.

It's partly tools, partly workflows.  Changing tools will to some degree
also necessitate changing workflows; I am not sure how much of the
discussion revolves around a desire for a different workflow or
different tools.

-- 
David Kastrup

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[nine . fierce . ballads]

On 2020/02/05 09:03:22, hahnjo wrote:
> In my opinion we should have a thread on lilypond-devel. In particular
it should
> lay out what the motivation is / which problem is to be solved. (see
questions
> by David and Karlin)

Other questions:

You're asking for agreement from "the whole LilyPond community" but this
is vague.  What specific impact do you expect this Code of Conduct to
have on the process of becoming and being a LilyPond contributor?  Will
a formal expression of agreement be required before one's patches are
considered?


https://codereview.appspot.com/575620043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Thomas Morley  writes:

> Am Di., 4. Feb. 2020 um 18:34 Uhr schrieb David Kastrup :
>>
>> "Phil Holmes"  writes:
>>
>> > - Original Message - From: "David Kastrup" 
>> >> Wow.  Ok, maybe I'll just apply this patch then (though I'll at
>> >> least
>> >> remove the conditioning on Apple here as the problem is rather likely
>> >> platform independent) and Phil may have another round.
>> >> --
>> >> David Kastrup
>> >
>> >
>> > Will kick this off again tomorrow.
>>
>> Thanks!
>>
>> --
>> David Kastrup
>>
>
> FWIW,
> cd gub
> make LILYPOND_BRANCH=stable/2.20 lilypond
> succeeded now on my machine, Ubuntu 18.04 64-bit

Again, I am impressed that this rather basic deal-breaker code
apparently occured only once in our code base.

-- 
David Kastrup