Re: non web_version of web.texi ?

[Graham Percival]

On Mon, Jul 06, 2020 at 11:26:46AM +0200, Han-Wen Nienhuys wrote:
> Just for clarity, I'm not against having web.texi as an info file or
> PDF file. It's just that I want to get rid of the special casing of
> web_version, which (when switched) off produces a doc with less links.

Ah sorry, it's been a while.  It looks like web_version is
essentially:

if web_version
LilyPond looks amazing, for example
@uref{examples.html#Classical-Music, classical music}
@uref{examples.html#Complex-Notation, complex notation},
else
LilyPond looks amazing and can display classical music.
endif


Do the @uref lines look reasonable in info and pdf output?
It's possible that I just assumed that it wouldn't work, and added
an unnecessary "fix".
(Come to think of it, it might be possible to replace those lines
with simple @ref{}s.)


if web_version
@divIf{homepage-sidebar}
... links to download and manuals page...

@html
   ... some kind of javascript...
@end html

endif


I added the latter in e343a09657b87891893a4cca13e6c1a3d775f34f,
probably because the pdf looked weird, but I can't recall the
exact circumstances.  Unfortunately the commit messages don't
explain much, as you've probably noticed.  :(

Sorry I couldn't help more,
- Graham

Re: non web_version of web.texi ?

[Graham Percival]

On Sun, Jul 05, 2020 at 10:38:50PM +0200, Han-Wen Nienhuys wrote:
> is there any other function of web.texi besides producing the
> lilypond.org website? I would like to get rid of the "-D web_version"
> distinction, that is making web_version always be true for the web
> document. Is there any reason to not do this?

IIRC there was an argument that all lilypond docs should be
available via info(1) and pdfs, and some parts of the website
qualified as "docs".  The general intro to our manuals, for
example.  Related commits:
ac3d9e3f836a56977ca09f89e7ffcfc189711743
a060fc94b65dbc25a7e1ec20f2f79a58036a2546
(general.texi was later renamed to web.texi)

The argument on the mailing list was probably in 2009, although
just possibly it was late 2008 instead.  I think that my original
idea was to just produce the html, while the person(s) who wanted
to have all docs available offline where you, Jan, John Mandereau,
and/or David Kastrup.  (It was definitely an emacs user!)
A few months later, I was glad that I lost that argument, as it
provided a "starting point" to the dozen or so pdf manuals.

I'm not aware of the current state & usage of lilypond docs, so I
have no position on whether it's worth keeping the "full offline
capability".  If there's a serious desire to make web.texi
HTML-only, then it might even be worth adding that to the tarball
of pdfs (if those are still being distributed).

Cheers,
- Graham

Re: Add Code of Conduct [Another RFC or not now?]

[Graham Percival]

On Sat, Feb 08, 2020 at 11:41:11PM +0100, David Kastrup wrote:
> Graham Percival  writes:
> > Within 2-3 weeks, I had squandered all of the good feelings and energy
> > sparked from that meeting.  I view that as my worst blunder from all
> > my years of involvement with LilyPond.
> 
> Hey, I had chalked this up to my slate.

Oh my goodness, I sincerely hope not!  I've always had very high
regard for your programming ability and diligence, and I can't
recall taking offense at any "harsh truths" that you threw my way.
(I was sometimes disappointed that they *were* true, but I never
blamed the messenger!)

No, there were a lot of other things happening in my life at the
end of 2012:

- I had finished writing my PhD dissertation, and I always viewed
  "completing a degree" as a chance to take stock of my life.
  I started the grand documentation project in 2007, 1 year before
  finishing my Masters', with the explicit goal of training my
  replacements so that I could quit in good conscience.  That new
  project was an attempt at another big project as I left lilypond
  again.

- I knew that my first postdoc job was at a university which had
  the "charming" idea of laying claim to all the intellectual
  property that I created, so I would be legally unable to
  contribute to lilypond.  (At least, not able to contribute code.
  Given that my main contribution at the time was emails and
  organization, I could have completed a bit, but it might have
  been awkward.)

- I knew that my publication record was not stellar, and no amount
  of time spent on lilypond would lead to a publication (of the
  type that mattered in my branch of academia, i.e. a "tier 1"
  IEEE or ACM journal).

- it had been almost ten years since I'd actually composed any
  music, so I was increasingly wondering why I was spending 10-15
  hours a week on LilyPond.

> In retrospect, I saw LilyPond in need to grow roots and you saw
> it in need to grow wings.

Yeah, that was another big mistake on my part.  In almost every
other instance of "hopeful wings" from 2009 to 2012, I'd argued in
favour of stability and keeping things moving (albeit slowly),
instead of taking risks.

> You've clearly been the much better organiser and motivator: the people
> who still keep the "shop running" are doing so in processes originally
> set up by you and given meaning by you.

Yes -- that's the "stability" part that I'm good at.

> And I am basically drawing blanks when thinking about how to
> make people pick up the slack when someone ultimately leaves.

My dream was always to have a "volunteer funnel".  For
non-programmers, find people willing to reliably do small tasks,
such as LSR, bug reports, translations, and documentation edits.
Then, after a few months of that, encourage them to move on to
more complicated tasks.

The tricky thing is:
- you need to expect at least 50% of people to flake out.  It's
  not because they're bad people, it's not because the lilypond
  community are bad people... that's just the nature of volunteer
  organizations.  I see it offline, too.  People understimate
  the difficulty of tasks, overestimate their time & energy, and
  underestimate the possibilty of other demands on their time
  (jobs, families, hobbies, etc).
- so the person organizing the volunteers (or ideally, the
  volunteers in a specific area such as bugs) needs to constantly
  be recruiting.  Well, not necessarily *constantly*, but if you
  ever think "ok, we've got all 7 days of bug reporters handled so
  I can relax", that's a danger sign.  If they're working well,
  then encourage 1 or 2 to move to a different task, and recruit
  new volunteers to fill the gaps.
- equally important, the "volunteer wrangler" needs to be
  emotionally prepared to see a lot of effort walk out the door
  when volunteers realize that they can't continue.

> I still think we should have been able to make this work better between
> us but have no idea how.

No, there was no fault on your side.  And to be fair to myself, it
wasn't really a "fault" on my side -- it was definitely time for
me to move on.  I should have handled it more gracefully (so yes,
I blame myself for that).  But there was nobody to blame for my
leaving the project; if anything, I should have left a year or two
earlier.  It was simply not a good fit with my life at the time.

Cheers,
- Graham

Re: Add Code of Conduct [Another RFC or not now?]

[Graham Percival]

On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote:
> Phil Holmes wrote 08/02/2020 17:24:56
> Subject: Re: Add Code of Conduct [Another RFC or not now?]
> 
> > - Original Message - From: "Karlin High"  > > However, I'd like to hear from David Kastrup and James Lowe first. To me, 
> > > their opposition registered as the strongest.
> > I remain strongly opposed to a CoC.
> > 
> As do I. I'm quite sure we on this list are all perfectly capable of civil
> and caring behaviour without having it spelled out in nanny-ish terms.

I've stayed silent since I'm not a contributor any more, but if
there's an "I'm sparticus" moment happening, then I will go on
record as saying that I think the proposed CoC is a mistake.

I don't have any reasons that haven't been mentioned already,
other than one meta-reason: proposals like this are very divisive.
Trying to have this discussion in the middle of a "final sprint
towards 2.20" was unfortunate.

I speak from experience on that last point: after the 2012
developer meeting at David's ranch (I think that was the year),
I was all fired up and started a round of divisive discussions
(I think it was the "grand lilypond input syntax standardization").
Within 2-3 weeks, I had squandered all of the good feelings and
energy sparked from that meeting.  I view that as my worst blunder
from all my years of involvement with LilyPond.

Cheers,
- Graham

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

[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: ’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: 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

Re: midi2ly on mac: midi.so wrong architecture

[Graham Percival]

On Fri, Jul 28, 2017 at 08:01:06AM +0200, David Kastrup wrote:
> ElRay  writes:
> 
> > FYI:  This has been reported as a bug -- in 2012.I will see if this is
> > something I can take-on in the next month or two.
> 
> I am pretty sure that Graham posted a patch for this on one of the lists
> one of the last times this was being discussed.

The patch was accepted in 2.19.55, and midi.c was removed:
d8677d345032752b564878e5da0ea17b112afcad
37893d923c65a5f1aec6c78f7225704d2ccec666

That said, the 2.18.2 release was (obviously) not updated, so
anybody using the stable release would still see the same error.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Discussed here: (issue 321830043 by fedel...@gmail.com)

[Graham Percival]

Cute solution, I like it.

Cheers,
- Graham

On Fri, Mar 31, 2017 at 10:49:27AM +0200, Federico Bruni wrote:
> It won't be in english only. It's up to translators. With this patch they can:
> 
> a) not translate the file, so the content of that section will be in english 
> _within a translated page_. No maintenance needed.
> 
> b) translate the file and maintain it across updates
> 
> I think I forgot to add a better comment at beginning of gsoc.itexi.
> I will do it in the coming days.
> 
> Sorry for the bad email subject. I didn't realize until today how Rietveld 
> creates it.
> 
> Il 31 marzo 2017 09:31:20 CEST, Urs Liska  ha scritto:
> >I don't really know what that technically means, but I'm OK with having
> >the GSoC page in English only.
> >
> >This page is being heavily edited for a certain period each year, and
> >the "target audience" has to be able to read it in English anyway.
> >
> >Urs
> >
> >
> >Am 31.03.2017 um 09:06 schrieb fedel...@gmail.com:
> >> Reviewers: ,
> >>
> >> Message:
> >> Please review
> >>
> >> Description:
> >> Discussed here:
> >>
> >https://lists.gnu.org/archive/html/lilypond-devel/2017-03/msg00277.html
> >>
> >> web: move Google Summer of Code information in included/
> >>
> >> So translators can choose not to translate this node of
> >community.itexi.
> >> GSoC page gets quite frequent updates and keeping the translations
> >> up-to-date may be cumbersome and not worth the effort (as GSoC
> >> applicants are required to speak english).
> >>
> >> Please review this at https://codereview.appspot.com/321830043/
> >>
> >> Affected files (+401, -385 lines):
> >>   A Documentation/included/gsoc.itexi
> >>   M Documentation/web/community.itexi
> >>
> >>
> >>
> >> ___
> >> lilypond-devel mailing list
> >> lilypond-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/lilypond-devel
> >
> >-- 
> >u...@openlilylib.org
> >https://openlilylib.org
> >http://lilypondblog.org
> >
> >
> >___
> >lilypond-devel mailing list
> >lilypond-devel@gnu.org
> >https://lists.gnu.org/mailman/listinfo/lilypond-devel
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Release issues?

[Graham Percival]

Proposed fix: https://codereview.appspot.com/316350043

In order to test it, I did upload website.make to the server and
build the website, and that version is still in use for the hourly
cronjob.  I figured that since the previous one wasn't doing
anything, there was no point waiting.

Cheers,
- Graham

On Tue, Mar 21, 2017 at 12:16:05AM +, Graham Percival wrote:
> Sorry, my bad.  For some reason it didn't twig with me that this
> would be release-blocking.  I'll upload a fix in 4-6 hours for
> discussion.
> 
> - Graham
> 
> On Mon, Mar 20, 2017 at 11:17:29AM +0100, Federico Bruni wrote:
> > I think that it's due to the "make website" problem described here:
> > http://lists.gnu.org/archive/html/bug-lilypond/2017-03/msg00034.html
> > 
> > 
> > 
> > Il giorno lun 20 mar 2017 alle 10:19, Urs Liska <u...@openlilylib.org> ha
> > scritto:
> > >Hi,
> > >
> > >are there any issues with the releases? The version bump commit to
> > >2.19.57 is over a week old, but the website still claime 2.19.56.
> > >
> > >Urs
> > >
> > >
> > >--
> > >u...@openlilylib.org
> > >https://openlilylib.org
> > >http://lilypondblog.org
> > >
> > >
> > >___
> > >lilypond-devel mailing list
> > >lilypond-devel@gnu.org
> > >https://lists.gnu.org/mailman/listinfo/lilypond-devel
> > 
> > 
> > ___
> > lilypond-devel mailing list
> > lilypond-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-devel
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Release issues?

[Graham Percival]

Sorry, my bad.  For some reason it didn't twig with me that this
would be release-blocking.  I'll upload a fix in 4-6 hours for
discussion.

- Graham

On Mon, Mar 20, 2017 at 11:17:29AM +0100, Federico Bruni wrote:
> I think that it's due to the "make website" problem described here:
> http://lists.gnu.org/archive/html/bug-lilypond/2017-03/msg00034.html
> 
> 
> 
> Il giorno lun 20 mar 2017 alle 10:19, Urs Liska  ha
> scritto:
> >Hi,
> >
> >are there any issues with the releases? The version bump commit to
> >2.19.57 is over a week old, but the website still claime 2.19.56.
> >
> >Urs
> >
> >
> >--
> >u...@openlilylib.org
> >https://openlilylib.org
> >http://lilypondblog.org
> >
> >
> >___
> >lilypond-devel mailing list
> >lilypond-devel@gnu.org
> >https://lists.gnu.org/mailman/listinfo/lilypond-devel
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website upload

[Graham Percival]

On Tue, Mar 07, 2017 at 11:47:31AM +0100, Davide Liessi wrote:
> Maybe an HTTP permanent redirect (308) should be added instead of a symlink, 
> see
> https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection

Why 308 instead of 301?  Google suggests 301:
https://support.google.com/webmasters/answer/93633?hl=en

I've added this to .htaccess:
## Temporary rule, pending larger examination of the setup
Redirect 301 /gsoc.html /google-summer-of-code.html
which should suffice for the current gsoc application process.

I'll revisit this in a few weeks.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Back in the Pond

[Graham Percival]

On Thu, Jan 19, 2017 at 02:01:40PM +0100, David Kastrup wrote:
> "Trevor Daniels"  writes:
> 
> > David, you wrote Thursday, January 19, 2017 10:18 AM
> >
> >> it would appear that my excursion into a regular workplace ended up
> >> somewhat shortlived.

Ouch, that sucks.  :(

> Well, the 2.20 release stoppers of course should be tackled.  Step 1
> IIRC was to contact the persons last having worked on three issues you
> identified.  Uhm, I'd be glad to leave that in Graham's hand, at least
> until it's clear that addressing those issues will have to be done by
> somebody else.

Right, I haven't forgotten, but I likely won't get to this until
Feb.  I've had a poor (and rare) reaction to some recent
vaccinations [1], and lost most of 5 days in the past two weeks.
I'm not certain how much energy I'll have after catching up on
work, and getting some work done for a Feb 4 board meeting for an
(offline) amateur music organization.

[1] I don't regret getting the vaccinations, since it's an
important public health issue and most people with whom I go
ballroom dancing are seniors.  For me personally, I'd be willing
to take my chances with the flu or even MMR, but for the elderly
those illnesses could well be fatal.  I just wish that I'd had a
better idea that I'd be one of the unusual people who have bad
side effects.  :(

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

python include path oddity with "make install"

[Graham Percival]

At the moment, doing:
  mkdir build
  cd build
  ../configure --prefix=$HOME/.local/
  make
  make install

results in python files which can't find lilylib.  This is
installed to:
$(PREFIX)/share/lilypond/$(VERSION)/python/

The relocation is supposed to be handled by:
python/relocate-preamble.py.in
but it seems to assume that "current" is a valid $(VERSION).
I know that GUB does add a symlink for "current", but that doesn't
appear to happen for "make install".


I can see a few different ways forward:
- figure out why the @lilypond_datadir@ replacement is going to
  /usr/...  instead of $(PREFIX)
- add a "current" symlink
- add some more directories to the system path in
  relocate-preamble.py.in

Unfortunately, I've lost a lot of steam on this and am not likely
to return to it until Feb.  I'd rather not hold back the
pure-python midi2ly change, so it would be awesome if somebody
else could clarify matters and/or fix it.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCHES - Countdown for January 8th

[Graham Percival]

On Mon, Jan 09, 2017 at 03:17:38AM +0100, Simon Albrecht wrote:
> I get a feeling we’re very good at producing misunderstandings right now…
> :-)

Yes.  :)

I have pushed the attached patch to staging.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: patch for git-cl

[Graham Percival]

On Sun, Jan 08, 2017 at 09:02:51PM +, Thomas Morley wrote:
> attached a little patch for git-cl to replace googlecodeissue by
> trackerissue in cl_settings.py, which will result in correct info in
> .git/config
> 
> How do we handle patches to git-cl?

In general, I'd recommend a PR, but I've applied this directly and
pushed.  Thanks!

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: patch for git-cl

[Graham Percival]

On Sun, Jan 08, 2017 at 10:15:24PM +, James wrote:
> On Sun, 8 Jan 2017 21:02:51 +
> Thomas Morley  wrote:
> 
> > attached a little patch for git-cl to replace googlecodeissue by
> > trackerissue in cl_settings.py, which will result in correct info in
> > .git/config
> > 
> > How do we handle patches to git-cl?
> 
> 
> I imagine pull requests to
> 
> https://github.com/gperciva/git-cl.git

That certainly works, but in this case I can handle it manually in
a few hours.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: official GNU LilyPond maintainer

[Graham Percival]

On Tue, Dec 27, 2016 at 05:25:08AM +, Graham Percival wrote:
> With David stepping down, LilyPond is left without an official GNU
> maintanier.

I have now resumed this position.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyDev 5.0 released

[Graham Percival]

On Wed, Dec 28, 2016 at 06:24:48PM +0100, Federico Bruni wrote:
> The default should be httpredir:
>  httpredir.debian.org
> 
> Have you tried again? I hope that it's just a temporary network problem.

Yes, seems to have been temporary.  I tried it 3 times yesterday,
but now it's working.

I currently have an awkward problem with virtualbox on Ubuntu
16.04; it keeps on resizing the window one step smaller, until
it's something like 50 pixels high and 300 pixels wide.  This
doesn't happen if I maximize the window.  Very odd, and not unique
to lilydev; I see this when I virtualize ubuntu 16.04, but not
other operating systems.  Very odd.


I've logged in, but it doesn't seem like like git-cl is installed?
The Contributor Guide says that it should be there:
http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

In a similar note, could we get a Terminal icon on the taskbar?
Most people won't know that they can get an xterm by pressing
ctrl-alt-t.


In a related matter -- and please forgive me if we've discussed
this before -- have we considered distributing an exported OS?  In
the virtualbox GUI, this is called "Export Appliance", but it can
be done in a standard format so that (in theory) non-virtualbox
people can run it.  This would let people "get started" much
faster, and without the intimidation of installing Linux.  It
might also be easier to customize a bunch of things, such as
git-cl, and even putting a git clone of lilypond in there.

I realize that this would increase the filesize; it looks like
1.8 Gb for the exported appliance, compared to 1.1 GB for the
installer.


(speaking of disk size, I see that the just-installed size is
3.1G.  What's pushing it so high?  texlive?  I poked around a bit,
but I couldn't find any packages that looks superfulous... maybe
I'm just out of date with how large installed software is these
days.  I must admit that I'm shocked to see that my desktop /usr/
is 8.5G !)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Offer to help development: Convert MIDI to Lilypond

[Graham Percival]

On Wed, Dec 28, 2016 at 08:21:58PM +0100, k...@aspodata.se wrote:
> > At that point, an interested person -- perhaps yourself? -- could
> > offer further patches which improved the quality of the lilypond
> > code.
> 
> Well, I'm working on theese:
>  http://turkos.aspodata.se/git/musik/bin/miditoly.pl
>  http://turkos.aspodata.se/git/musik/bin/midi_to_lilypond.tex

Hmm.  At the moment, there is no perl used in user scripts in
lilypond, and thus we do not distribute a perl interpreter as part
of our application bundle.  Adding perl would be a significant
complication.

That said, I'm quite willing to believe that your experience with
miditoly.pl could help inform the conversion process in midi2ly.py
-- what types of quantization work best, or how to decide which
accidental to use, etc.  Once we have the basics working, Joe may
want to investigate more advanced techniques.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Free alternatives to Rietveld?

[Graham Percival]

On Wed, Dec 28, 2016 at 06:35:30PM +0100, Federico Bruni wrote:
> It would be possible to add a configuration option in git-cl so
> you can login in rietveld with a specific browser different from
> the default one?

Certainly!  In the source, I see:

-
If your browser is on a different machine then exit and re-run
upload.py with the command-line parameter

  --no_oauth2_webbrowser
-

IIRC that prints a URL string, which you can open with whatever
browser you want (on whichever computer you want).

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Offer to help development: Convert MIDI to Lilypond

[Graham Percival]

On Tue, Dec 27, 2016 at 08:43:34AM +0100, k...@aspodata.se wrote:
> Graham:
> > That is correct; the python midi2ly conversion is quite
> > independent of the rest of LilyPond.  As a result, it is an
> > excellent place to begin!  :)
> 
> So I propose that a better course of action would be to research

Thank you for the suggestion.

At the moment, it appears that midi.c is broken on at least one
architecture.  Fixing it would be a pain, and would do nothing to
reduce the problem it poses.  Moving to a completely python
solution would represent a solid step forward, both in terms of
reducing technical debt, and also in terms of a new contributor
getting familiar with our development process.

At that point, an interested person -- perhaps yourself? -- could
offer further patches which improved the quality of the lilypond
code.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Free alternatives to Rietveld?

[Graham Percival]

On Tue, Dec 27, 2016 at 02:39:09PM +, James wrote:
> On Tue, 27 Dec 2016 13:33:11 +0100
> Simon Albrecht  wrote:
> 
> > Whatever the reason for this weirdness, I think it would really be 
> > better if we had a code review tool which didn’t rely on external
> > login providers. Is there really no free alternative?
> 
> We had a 'similar' discussion back in 2013
> 
> http://lists.gnu.org/archive/html/lilypond-devel/2013-09/msg00351.html

Heh, yes!

I'm aware of problems with the existing setup -- in fact, my first
few patches were delayed by half a week because I had problems
setting it up.  Quite apart from the loss of time, that was a huge
drain on my energy and motivation.

A week ago, I started investigating alternatives.  As always, my
primary motivation is *not* adding any additional burden to our
experienced developers.  I have not yet reached the point at which
it would be useful to discuss any proposals on -devel, though.

(As we can see from the 2013 emails, a very wide-ranging
discussion quickly becomes bogged down and fails to produce
results.  If anybody is very interested in the "alternatives"
question and is willing to do 2-5 hours of work that will probably
end up being discarded, feel free to contact me off-list.)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyDev 5.0 released

[Graham Percival]

On Wed, Dec 14, 2016 at 01:53:06PM +0100, Federico Bruni wrote:
> Eventually I managed to build the new ISO.

Thanks for all this work!  I get an invalid network mirror when I
try to install it.  Do you have a default valid set, or is it
failing to connect to the generic Canadian debian server?

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

official GNU LilyPond maintainer

[Graham Percival]

With David stepping down, LilyPond is left without an official GNU
maintanier.  Does anybody want to do fill this role?  The relevant
documentation is:
https://www.gnu.org/prep/standards/html_node/index.html
https://www.gnu.org/prep/maintain/html_node/index.htm

If nobody is interested in the position, I am willing to take it
up again.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Can I develop with Raspberry Pi 3

[Graham Percival]

On Mon, Dec 26, 2016 at 12:47:29PM -0500, Joseph Austin wrote:
> Is it possible/practical to  run LilyDev on Raspberry Pi 3?

Unfortuantely not; LilyDev is compiled for x86 CPUs, whereas the
Pi 3 has an ARM CPU.

> In other words, is that a realistic alternative to setting up a
> virtual machine or configuring a MacBook to run native?

Unless your MacBook is 10 years old, it would be much faster to do
LilyPond development within a virtual machine on your MacBook.


That said, if you are only working on midi2ly, then you don't need
the full LilyPond developer infrastructure.  In fact, all you need
a python interpreter (and arguably git for the source code); MacOS
comes with python already.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Offer to help development: Convert MIDI to Lilypond

[Graham Percival]

On Mon, Dec 26, 2016 at 11:44:15AM -0500, Joseph Austin wrote:
> I am offering to help with the project of converting midi2ly
> from C to Python, or more generally converting MIDI to Lilypond.

Excellent!  I'd be delighted to serve as your mentor.

> I'm not sure if this is a good place for someone new to Lilypond
> internals to start, but it seems this should be a relatively
> independent utility so I shouldn't need a significant background
> in the internals.

That is correct; the python midi2ly conversion is quite
independent of the rest of LilyPond.  As a result, it is an
excellent place to begin!  :)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: linux-ppc harfbuzz GUB build error

[Graham Percival]

On Sun, Dec 11, 2016 at 04:44:40PM +0100, Hans Aikema wrote:
> 
> The official requirements for building:
> INSTALLING
> 
> * You need
>   - about 9 GB of free space (for all platforms)
>   - standard unix shell utilities: cat, cp, install, mv, rm, sed, ...
>   - a standard unix development environment with GCC and G++
>   - Python 2.4 or newer (2.5, 2.6, 3.0 are known to work)
> 
> are rather vague (on points 2 and 3) and in a Dockerized linux env you 
> usually have the bare minimum available and all else needs to be added. Hence 
> the /usr/bin/file was missing on my system. On a regular CentOS I assume it 
> would’ve been present.

Yes, absolutely.  I've begun expanding the definition of "standard
unix development environment" in the README; please make a branch
and add to that list as you discover more missing items.  We seem
to have more interest in GUB these days, so making it easier to
get started would be great.  :)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: website: texinfo macros for both ID and classes

[Graham Percival]

On Mon, Dec 05, 2016 at 01:13:26PM -0500, Paul wrote:
> On 12/05/2016 12:35 PM, Graham Percival wrote:
> 
> >>This would be good to have in general and more intuitive for
> >>those used to html.
> >I'm not convinced.
> 
> As someone who knew html and went through the process of figuring out how to
> contribute to the LilyPond website, I would have found it more intuitive and
> useful to have.  There was a point where a div with both Id and class was
> needed and there was no way to do it even though this is the most basic and
> common thing in html.

Sorry for the delay.

I'm still not convinced that a div with ID and class is actually
needed.  Can you remember the specific example?

> I'm just trying to smooth out a point of friction that I encountered, but
> sure, there are probably other priorities.

Right, and that's a great move!  I'm just not convinced of the
details in this case.


I don't want this to be advertized on lilypond-user yet since it's
still too soon after the latest website fracas, but I've prepared
a repository so that people can easily experiment with CSS.  It
has the normal index.html, the pictures used by that file, and the
original CSS.  Anybody interested is encouraged to copy the "orig"
directory into a new one, then edit the new CSS as much as they
want.
https://github.com/gperciva/lilypond-web-css
You can see the results here:

http://percival-music.ca/lilypond-web-css/orig/
http://percival-music.ca/lilypond-web-css/simple/

(yes, I ran out of patience when I got to the point of choosing a
color for the "Beautiful Sheet Music" header)

Over the next few days / weeks, I'll continue to edit the "simple"
CSS, and maybe make one or two other examples.  None of this is
intended to be merged with lilypond; I just want to demonstrate
how easy it is to make huge changes with only the CSS.

This way, the next time somebody expresses interest in the
website, they'll have a much clearer idea of what's involved and
what the limitations are.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: bypassing the patch countdown

[Graham Percival]

On Wed, Dec 07, 2016 at 11:58:14PM +0100, Urs Liska wrote:
> Am 7. Dezember 2016 23:34:39 MEZ, schrieb Graham Percival 
> <gra...@percival-music.ca>:
> >(please note that I'm not suggesting that anybody should feel
> >obligated to make such typo fixes -- instead, I'm checking that
> >the "door is open".  So that if we manage to get 1 or 2 users
>
> In the current case the point is not that it would take a
> significant  effort to update the news but rather that it's not
> woth touching at all, given the temporary nature of the
> information. 

Oh, absolutely, I'm not suggesting that anybody here should update
the news!  I'm just checking that if a user thinks they're capable
of making such contributions, I can encourage and mentor them with
a good conscience.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

bypassing the patch countdown

[Graham Percival]

I was going to wait a month or two before suggesting this, just to
make sure I was fully "up to date", but I'll jump in now.

We instituted the policy of patch countdowns and Patchy after the
lengthy wait for 2.14.0, which was due to a large number of
regression bugs due to patches which either broke the compile, or
broke previously-working output.

However, even after that, I still pushed some commits directly to
staging, bypassing the countdown.  Obviously I did this for
updating the VERSION when making a release, but I also did it for
a few typo fixes as well.

Is this still an accepted practice?  If not, I suggest that it
should be.  If I had to formalize it, I'd say something like "if
two developers with push ability agree that a fix is trivial and
obvious, it can go straight to staging".


(please note that I'm not suggesting that anybody should feel
obligated to make such typo fixes -- instead, I'm checking that
the "door is open".  So that if we manage to get 1 or 2 users who
are able to fix typos, and those fixes are very obvious, they
wouldn't need to wait 2-4 days.  In this case, the "two
developers" would be "1 mentor, and the release or patch
meister".)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[Graham Percival]

On Mon, Dec 05, 2016 at 06:03:28PM +, Carl Sorensen wrote:
> 
> On 12/5/16 10:28 AM, "lilypond-devel on behalf of Graham Percival"
> <lilypond-devel-bounces+c_sorensen=byu@gnu.org on behalf of
> gra...@percival-music.ca> wrote:
> 
> >The website *is* tied to the documentation.  That decision was
> >made in 2009, and the reasons are just as valid today.
> 
> I believe you when you say this.  But I am having a hard time finding a
> record of the decision.  I expected to find it in the CG under
> Administrative Policies or under Website work.  I couldn't find it either
> place.  Can you help me find a pointer to the discussion and/or the
> decision rationale?

Good question, and I still don't have a good answer.  This was
before we started keeping records of any decisions.  The earliest
I found was this:
http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00574.html
which didn't spark a whole lot of discussion.  The current website
didn't start to become visible until late 2009.

I had a vague memory of a much more in-depth discussion, but
perhaps that was sometime in 2010 or 2011.  I'll continue to trawl
through the archives to see if there's more info.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: website: texinfo macros for both ID and classes

[Graham Percival]

On Mon, Dec 05, 2016 at 11:49:27AM -0500, Paul wrote:
> For the website I'm thinking about adding a macro that can create a div with
> both an ID and classes.

Why?  What problem would this solve?

> This would be good to have in general and more intuitive for
> those used to html.

I'm not convinced.

Before changing the underlying texinfo macros, much less the build
system or language used (which is not what Paul is suggesting, but
I know that those ideas are out there), I'd like to see somebody
make an honest effort at working on the CSS.

In particular, to make the website look acceptable on small
screens.  This would take 2-5 hours, depending on how familiar
that person is with CSS and web browser testing.

I don't think that's too much to ask.  If nobody is prepared to
even do that much, then we certainly don't want them to spend time
and effort on larger redesigns that may never be completed.  I'm
available to mentor this task.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[Graham Percival]

On Mon, Dec 05, 2016 at 09:24:54AM +0100, Urs Liska wrote:
> 
> If this intends to codify the website being tied to the documentation I
> don't really like that.

The website *is* tied to the documentation.  That decision was
made in 2009, and the reasons are just as valid today.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New LilyPond website

[Graham Percival]

On Fri, Dec 02, 2016 at 07:50:50PM +0100, Jean-Charles Malahieude wrote:
> I've already given it a try, but get stopped by some errors I don't know how
> to resolve (I've no knowledge about perl). Three patches are available for
> anybody willing to help me… I can compile the English version, except that I
> don't get the TOC sidebar.

Hmm, sounds like there's some duplicated effort there.  In July
2015, we created:
https://github.com/gperciva/lilypond-texinfo
to try to update lilypond-texi2html-init.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Stepping up, contributor mentoring

[Graham Percival]

On Sat, Dec 03, 2016 at 11:34:01AM +, James Lowe wrote:
> I have created
> 
> https://sourceforge.net/p/testlilyissues/issues/5006/
> 
> For the 'CSS change' Rietveld that I see you uploaded on behalf of Mr.
> Roper just so it gets on my radar (and the countdown, including the URL
> that Phil kindly set up for developers to have a quick overview -
> http://www.philholmes.net/lilypond/allura/)

Thanks!  Since Mr. Roper dropped out, I removed that issue, but
it's good to know the process is in place.  :)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Stepping up, contributor mentoring

[Graham Percival]

On Tue, Nov 29, 2016 at 11:37:04PM -, Trevor Daniels wrote:
> 
> Graham Percival wrote Tuesday, November 29, 2016 11:11 PM
> 
> > So, are there any vacancies on the Bug Squad?  I've signed up for
> > sourceforge (username: gperciva).  
> 
> I've added you to SF as a Developer (gives you Read, Create, Update
> permissions for the LP Issues at 
> https://sourceforge.net/p/testlilyissues/issues/ ).

Hmm.  Sourceforge seems to have forgotten my account -- I couldn't
log in, and the recovery emails didn't work.  So I tried to create
a new account with the same username, and it appeared to work.
This is not encouraging.  :(

It could simply be that I used to have an account there, and it
got confused because I created an account with the same name as a
deleted account.

Could you please try adding "gperciva" to the SF Developer list
again?  If my suspicions are correct, this account will also
disappear, in which case I'll choose a different username.

(I just tried to create a second account, but it recognized that I
already had one tied to my email address and refused to add it.)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Stepping up, contributor mentoring

[Graham Percival]

Hi all, I'm back.

So, are there any vacancies on the Bug Squad?  I've signed up for
sourceforge (username: gperciva).  Other than that, my primary
interest remains in organization / mentoring new contributors.
Has anything changed in regards to that in the past four years?
Or shall I jump straight in?  I see that "Contributor 1.4 Mentors"
hasn't changed.

Anything else I should know?  I've skimmed the past month of this
mailing list.


(I was planning on waiting until the new year, but David's news
made me re-evaluate my health now, and I think I have the energy
to take on more stuff.  To make a long story short: depression,
burnout, quit academia, moved back to Vancouver, recovery.  Also,
started ballroom and swing dancing!  Great fun, absolutely
recommended, *especially* for other shy, socially anxious computer
geeks.  Despite that help, I'm still not 100% recovered, but I'm
content with my progress, and I think that doing more volunteer
work will help.)


Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.org - file storage

[Graham Percival]

On Sun, Aug 30, 2015 at 05:57:45PM +0200, Jean-Charles Malahieude wrote:
 
 BTW, is there any difference between download/source and download/sources ?

I'm pretty certain that one is a symlink of the other.  If not, then one
was a place to store some odd tarballs for GUB to download.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.org - file storage

[Graham Percival]

On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote:
 We also have source files back to 0.0 and 1.0.  I assume we could
 never recreate these from Git, but are we ever going to need to?  It
 certainly seems pointless keeping lots of source tarballs, given
 that all the more recent history is in Git.

I think it would be nice to keep the ancient history around; software
archeology research sometimes look at open-source projects.  That said,
they don't necessarily need to be on that particular web server.
Something like Amazon Glacier could work well for that, or maybe google
drive... there are other storage platforms available.
(and no, I'm not in a position to offer to take care of this)

I fully support deleting all test-output for non-current development
versions.  (though again, in an ideal world they would be stored on some
other server or service)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: mentoring opportunity: anybody claiming to care about the website

[Graham Percival]

Great to have you on board!  I've sent a private email to you
about the first few steps.

Cheers,
- Graham

On Sat, Jul 25, 2015 at 03:02:36PM +0100, Kevin Barry wrote:
I have some unexpected free time and would like to do this. Should I
contact you off list?
Kevin
 
On Sun, Jul 19, 2015 at 4:31 PM, Graham Percival
[1]gra...@percival-music.ca wrote:
 
  Add weight to your opinions by showing that you're not afraid of
  getting your hands dirty.
  texi2html is a vital part of the documentation.  It's currently
  used for the website as well, but that is almost incidental to its
  use for the rest of the documentation.
  [2]https://code.google.com/p/lilypond/issues/detail?id=1000#c20
  [3]https://code.google.com/p/lilypond/issues/detail?id=1000#c21
  I cautiously estimate 20 hours of work for the non-translation
  portion[1].  I am willing to mentor.  Programming ability is
  desirable, but not strictly required.
  [1] at the present time, I am not willing to look into the
  translation system in sufficient detail to offer an estimate of
  how much work it would take.  If we complete the English part, and
  those involved wish to continue, then I promise to also mentor the
  translation part.
  - Graham
  ___
  lilypond-devel mailing list
  [4]lilypond-devel@gnu.org
  [5]https://lists.gnu.org/mailman/listinfo/lilypond-devel
 
 References
 
1. mailto:gra...@percival-music.ca
2. https://code.google.com/p/lilypond/issues/detail?id=1000#c20
3. https://code.google.com/p/lilypond/issues/detail?id=1000#c21
4. mailto:lilypond-devel@gnu.org
5. https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

mentoring opportunity: anybody claiming to care about the website

[Graham Percival]

Add weight to your opinions by showing that you're not afraid of
getting your hands dirty.

texi2html is a vital part of the documentation.  It's currently
used for the website as well, but that is almost incidental to its
use for the rest of the documentation.
https://code.google.com/p/lilypond/issues/detail?id=1000#c20
https://code.google.com/p/lilypond/issues/detail?id=1000#c21

I cautiously estimate 20 hours of work for the non-translation
portion[1].  I am willing to mentor.  Programming ability is
desirable, but not strictly required.

[1] at the present time, I am not willing to look into the
translation system in sufficient detail to offer an estimate of
how much work it would take.  If we complete the English part, and
those involved wish to continue, then I promise to also mentor the
translation part.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)

[Graham Percival]

On Tue, Jul 07, 2015 at 12:22:27PM +0200, Dave Plater wrote:
 On 7/7/15, Dave Plater dplater.l...@gmail.com wrote:
  Oh, there's a pretty big chunk of custom stuff in lilypond
  texi2html.  See past discussion here:
  https://code.google.com/p/lilypond/issues/detail?id=1000

  is this issue likely to be resolved soon or is it as complex as the
  guile 2.x issue and I'm going to have to create texi packages to build
  the documentation?
  See https://bugzilla.novell.com/show_bug.cgi?id=936870

It's not as complex as guile 2.x.  If somebody has basic knowledge
of perl (which isn't hard to acquire) and texinfo (essentially
just knowing it's a doc format with @commands), and is good at
diagnosing and communicating problems, then I would cautiously
estimate 20 hours for this task.  10 hours of investigation and
rewriting by oneself, plus another 10 hours of creating minimal
examples, sending them to the texinfo list to ask for help, then
integrating the solutions into the updated thing.

This could very feasibly be done by somebody new to lilypond
development.

oh, two slight snags:
1) once it was updated to the new texinfo, our build scripts will
probably need some slight adjustment.  That is not do-able by
somebody new to lilypond, but I'd estimate 1 hour from a current
lilypond developer to get that done.

2) it is possible (or even likely) that texinfo will need to be
changed in order for us to do what we want.  I'm certain that if
somebody has a minimal example of the problem, and a compelling
justification for why we want to achieve the desired output, the
texinfo people will be happy to add whatever features or bugfixes
are required in texinfo.  But this *would* add another delay for
being able to build lilypond on a stock distribution with texinfo
5.x.
(that said, if I'm correct about requiring texinfo changes, this
will need to happen at some point so all the more reason to jump
on this now)

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improving the Contributors Guide and LilyDev

[Graham Percival]

On Mon, May 04, 2015 at 03:02:32AM +, Carl Sorensen wrote:
 A. Suggestions for LilyDev3:
 
 All of these suggestions would actually probably be for LilyDev4.  I'm not
 sure that we will make another release of LilyDev3.  But if we did, I'm
 still happy to host it.

If somebody is available and interested in preparing lilydev4, I
suggest splitting the list of improvements into lilydev4-stuff and
CG-stuff.


 (And/or in the CG walk the reader through the steps to change the editor
 settings.)
 
 This is an immediately-accessible thing to do.

Yes, although the editor settings can be done in advance in
lilydev4.  (I believe that /etc/skel/ is the place to look at, but
I know that somebody already figured this out and it wasn't me)

The CG could also have a section for turning a typical ubuntu
installation into lilypond development-ready (a shorter name
would be better), which gives details about this, setting PS1,
etc.  But ideally LilyDev4 should have as much as possible done in
advance, so that interested contributors can jump into
contributing.


 In general avoid having sections that basically repeat each other in
 different ways, for example, consider merging:
 1. Git for the impatient (3.2.2) and Basic Git procedures (3.3)
 
 There are reasons (perhaps historical) for this duplication.  3.2.2 is
 supposed to be briefer than 3.3.

The main reason is that when I wrote 3.2.2, I forgot that 3.3
existed.  Either that, or I thought that 3.3 was too long.  I
forget which.

Either way, I don't think we need both sections.

 2. Compiling with LilyDev (2.3) and Compiling (4.x)
 
 2.3 is about getting it set up with LilyDev.  4.x is about general work
 whether with or without LilyDev.  We are much stronger about recommending
 the use of LilyDev than we were when the CG was originally written, so
 perhaps it's time to make a change here.

I think it's worth keeping a section about compiling for
non-lilydev, but perhaps something like Advanced unix compiling
(again, bad name) would be better.  Basically, make sure that 4.x
is clearly about general work.
(as an advanced Linux user, I would be annoyed if I had to wade
through lots of hand-holding in a discussion about how to compile
an open source project)


 We certainly want to make the CG accessible for new users/developers.  But
 we also want to have the CG useful for old developers and those
 experienced with other software development environments.   Perhaps we
 need to clarify these two different use cases, and separate them out more
 carefully in the CG.  But IMO we need to avoid making the CG only useful
 for newbies.

Yes.

 Thanks again for looking at this.  Certainly improving the CG is an
 important part of the health of LilyPond.

Absolutely!

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fwd: Google Code shutting down

[Graham Percival]

On Fri, Mar 13, 2015 at 11:33:22AM +0100, Han-Wen Nienhuys wrote:
 I can click the export button so all the issues are migrated to
 github. Thoughts, ideas?
 
 Didn't someone setup a lilypond organization at github?

There was some discussion about that, which spilled over to
gnu-hackers or gnu-devel or whatever it's called.  Pending some
investigation about the javascript libraries or scripts used on
github.com, it's tentatively seen as reluctantly acceptable to
host GNU software there.

A few people spoke highly in favor of gitlab, but I'm not familiar
with them so I can't say anything one way or the other.


In addition to moving the issues, the issue handling scripts
would need to be updated.  Things like git-cl, patchy, and the
whole patch-submission system.  That will be a non-trivial effort.

- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond documentation build issue (both 2.18.2 and 2.19.16)

[Graham Percival]

On Mon, Mar 09, 2015 at 01:29:39PM +0100, David Kastrup wrote:
 Petr Gajdos pgaj...@suse.cz writes:
  If this is relevant, texi2html-5.0/texi2html.pl do not contain
  sub get_index in contrast of texi2html-1.82/texi2html.pl.
 
 Whoa.
 
 That one certainly looks like it will need attention soonish.  I did not
 realize that we had what amounts to such a large modification of
 texi2html in our code base.

Oh, there's a pretty big chunk of custom stuff in lilypond
texi2html.  See past discussion here:
https://code.google.com/p/lilypond/issues/detail?id=1000

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB update

[Graham Percival]

On Sun, Jan 04, 2015 at 04:33:05PM +, Phil Holmes wrote:
 I assume what is happening here is that the manual install places the mpc
 libraries where the gcc configur can't find them.  In any case, doing this
 manually defeats the object of a self-building package builder.  So what
 would be really helpful would be for someone who understands all the python
 stuff that GUB does could point me to how to add the new dependency to GUB
 for MPC.

Wouldn't it be here?
https://github.com/gperciva/gub/blob/master/gub/specs/gcc.py#L16

However, first you need to add a mpc.py in that directory.  The
contents of that file should start of being something like
https://github.com/gperciva/gub/blob/master/gub/specs/tar.py
(picked fairly randomly)
Note the toolsAutoBuild part -- if MPC is autotools, then the
configure should be relatively straightforward.  Maybe even
something like
https://github.com/gperciva/gub/blob/master/gub/specs/faac.py
(again chosen randomly)

I'm sure that right now you're wondering why some (most?) of the
spec files are much much nastier than faac.py.  The answer is that
pretty much all of that nastiness is working around bugs in the
original package's build systems.

After you add mpc.py, test that in isolation before trying make
bootstrap.  It's entirely plausible (or even likely!) that you'll
be able to build mpc with the default ubuntu, but it'll fail on
some cross-compilation step.  But check the native build first.
:)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

[Graham Percival]

On Thu, Oct 09, 2014 at 10:21:45AM +, tdanielsmu...@googlemail.com wrote:
 I've not followed the corresponding email discussion closely, and maybe
 I've missed something, but how is this better than simply using \obreak
 for an original break, and \nbreak for a new, required, break, having
 defined
 
 obreak = \break
 nbreak = 
...
 That seems so simple anyone can do it without adding anything to the
 base code and almost a page to the documentation.

This method is already in the documentation!  At least, it used to
be... Learning Manual, tips for typesetting or something like
that?  it's just possible it was moved to Notation or Usage at
some point.  But it was definitely in the docs ten years ago.
(yes, literally 10 years ago.  Mao, where did the time go?)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Compact Chord Symbols Patch

[Graham Percival]

On Tue, Oct 07, 2014 at 12:53:53PM +0100, James wrote:
 I think we could improve the notes in the contributor's Guide
 generally. Having had to help three or four people over the last few
 months with a patch or two, I get how the instructions are probably
 rather confusing if not intimidating.

I think the most important point would be to have a single
checklist for what should be done.  Two years ago, the CG had at
least three such lists, and I was aware of mistakes in two of
them.  I don't know what's changed sinc then, though.

Having a single list has two advantages: it's an obvious thing to
refer to, and since it focuses attention from both readers and
CG-writers, mistakes should be more obvious (and thus easier to
fix).

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: es means ees???

[Graham Percival]

On Mon, Oct 06, 2014 at 01:41:30PM +0200, David Kastrup wrote:
 Richard Shann rich...@rshann.plus.com writes:
 
  Here, instead of ees, is written es.
 
 I read
 
 In Dutch, aes is contracted to as, but both forms are accepted in
 LilyPond. Similarly, both es and ees are accepted. This also applies
 to aeses / ases and eeses / eses. Sometimes only these contracted
 names are defined in the corresponding language files.

Yes.  In case anybody was wondering, I deliberately moved the as
and es contractions from the tutorial into the NR ages ago.  For
people unfamiliar with that notation, it's easier to remember
letter name plus -es or -is rather than introducing all the
contractions.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How can I change my email address for code reviews?

[Graham Percival]

On Thu, Sep 18, 2014 at 07:01:02PM -0400, Dan Eble wrote:
 I’m using LilyDev.  ~/.gitconfig says nine.fierce.ball...@gmail.com.  I’ve 
 tried removing ~/.last_code_review_email_address.  I’ve even gone as far as 
 running rm -f ~/lilypond-git and getting it again with lily-git.tcl.  No go.  
 git cl upload still uses the old address.  What am I missing?  Thanks in 
 advance.

Take a look at your ~/.gitconfig .  If lily-git.tcl inherits your
old address from somewhere, it must be a user setting such as
$HOME/.gitconfig or an export GIT_EMAIL or something like that.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

two patches for lilypad: accept?

[Graham Percival]

Hi guys,

I see that there's two patches for lilypad:
https://github.com/gperciva/lilypad/pull/4
https://github.com/gperciva/lilypad/pull/3

Are these good?  I think that Phil Holmes (and Christian Hitz) can
accept them with the github interface, but if not, please let me
know if I should accept them.

Unfortunately I'm preparing for a presentation at work (I'm now at
AIST, Tsukuba, Japan) on Monday, and in any case I've forgotten
most of what I used to know about GUB / lilypad / etc.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2507: Stop the entanglement of context properties and grob property internals (issue 126280043 by d...@gnu.org)

[Graham Percival]

On Fri, Aug 15, 2014 at 07:58:26AM +, d...@gnu.org wrote:
 At any rate, putting Graham in the Cc since event-listener.ly or
 equivalent code is purportedly used in Vivi.  The change in
 event-listener.ly is independent of this issue itself and should be
 applied to any similar code in order to avoid getting flaky results.

Thanks for the heads-up!  Vivi turned out to be a dead end (the
machine learning technique I used was really inappropriate for the
problem), but I'm still doing things with lilypond output.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rietveld with Google two-factor authentification

[Graham Percival]

On Wed, Jul 16, 2014 at 03:11:31PM +0200, Alexander Kobel wrote:
 My usual password is not accepted (which is good), since
 git-cl does not ask for the second-factor token (which is bad).  And
 obviously git-cl is not able to cache the credentials - I get
 
 Could not find stored credentials
   $HOME/.lilypond-project-hosting-login
 each time.

That is correct, git-cl does no caching, no fancy authentication,
etc.  It attempts to read the above file, and it takes the first
line in that file as the username and the second line in that file
as the password.  That's all it does.

Patches to git-cl most welcome.  :)

I've heard of this two-factor authentication, but I've never
used it (even in my personal life), and git-cl was my first foray
into authentication on foreign servers.  I was kind-of expecting
that somebody familiar with python+google+authentication to take
30 minutes (rough estimate for somebody familiar with the above)
to fix it after a few months, but obviously there's been no takers
yet.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: astyle 2.02

[Graham Percival]

On Sun, Jun 29, 2014 at 12:08:56AM +0200, Janek Warchoł wrote:
 If badly formatted = different than what fixcc.py would produce,
 i would say that LilyPond often gets badly formatted code - as you
 wrote, running fixcc now results in 400 lines of changes.

This could, of course, be completely automated.  Once fixcc.py has
been run on the whole source code, each patch could be tested to
see if running fixcc.py on it produces any changes.  If so, then
the patch would be automatically rejected and the submitter would
be asked to run fixcc.py before re-submitting the patch.  A less
strict method of this would be to simply produce an automated
warning.  Or this could be deferred to the merge staging side of
things -- if fixcc.py produces any changing on staging, then it is
not merged with master.

The question to ask is where do you want the burden of producing
properly formatted code?

- a volunteer who runs fixcc.py manually once a year?
  (this also produces code reformatting commits which disrupt
  git blame)
- an automated process which demands that the initial submitter
  format the patch?
- an automated process which demands that the pusher format the
  patch?
  (note that with new or casual committers, the pusher is not
  the same as the committer)

I favour the first or third option; people heavily involved in
lilypond can set up a git hook and always have properly formatted
code (whether they write the patch themselves or simply push
somebody else's patch).  Asking casual committers to have a
specific version of astyle seems like a high burden.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: astyle 2.02

[Graham Percival]

On Mon, Jun 23, 2014 at 09:28:24PM -0400, Devon Schudy wrote:
 The cases where 2.04 does worse than 2.02 are minor; I don't think
 they're enough that fixcc.py should refuse to use it.

Thanks for the analysis of astyle 2.02 vs. 2.04.  I support
switching to 2.04.

However, fixcc.py should reject any version other than the
specific version we want.  Otherwise, you could run it on your
computer (and push it), then I could run it on my computer (and
push it), then you could do the same thing, and basically we'd end
up with an infinite sequence of formatting changes.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New ponding: Urs Liska Berne lectures (issue 94960043)

[Graham Percival]

On Fri, May 02, 2014 at 06:02:48PM +, lilyli...@googlemail.com wrote:
 Updated patch, now applied to master.

I hope you mean now applied to staging.  You should never push
anything directly to master.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Python 3 support

[Graham Percival]

On Sun, Mar 16, 2014 at 04:41:46PM -0400, Julien Rioux wrote:
 I think the following would be a good 1-2 punch approach for the
 current development cycle: First, upgrade python in GUB and make
 sure we can build current dev and stable branches of lilypond from
 it. Then bump the python requirement in the dev branch and start
 migrating to a codebase that supports python 2.6+ and python 3+

Sounds great!  Thanks for working on this.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: long-term goals (was: Lines and Ties and Slurs oh my!)

[Graham Percival]

On Sat, Mar 01, 2014 at 07:07:39PM -0500, Kieren MacMillan wrote:
  I’ve know someone at Carnegie-Mellon University who is well-connected
  in the computer and music departments (he is both a composer and a 
  programmer).
  I approached him recently with the idea of getting involved with Lilypond.
  
  He said:
  
  One possibility is that sometimes there are software engineering projects
  looking for tasks, so I might be able to point a class project at 
  Lilypond
  in the future.
  I'm curious if there's a short summary of the direction for large-scale 
  work on Lilypond.
  
 
 With all due respect for everyone’s time, I am bringing what is in my opinion 
 an unprecedented opportunity to the Lilypond team — and I’ve got no response 
 worthy of bringing back to my contact.
 
 Can nobody give me an “official” answer for him?

My guess is that people are leery of inviting newcomers who
might expect mentoring, when there is clearly no mentoring spots
available.  Our code base is notoriously difficult to learn, and
if we specifically send a list of tasks to a professor, in my mind
there's an implicit offer to welcome (if not teach) a student who
tries to work on one of those tasks.

This doesn't bode well for the long-term survival of lilypond, but
that's something that's been discussed off and on for at least the
past 8 years, so I don't expect any immediate change on this
matter.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Pre-review questions about image(s) and translations

[Graham Percival]

On Wed, Jan 15, 2014 at 08:33:37AM -0500, Carl Peterson wrote:
My first instinct is to prepare an SVG file that could be processed with
inkscape or another program as part of the make process.

That is not do-able for the website due to our hostingbuild
situation.  I've commented on this twice before, so please read
the CG chapter on the website before continuing in this direction.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Run grand-replace to update copyright

[Graham Percival]

On Sun, Jan 05, 2014 at 10:38:04AM +0100, Werner LEMBERG wrote:
 
  I do not believe that there is a notion of package copyright in
  most countries' laws.
 
 On page
   http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
 I see this:
 
   To update the list of year numbers, add each year in which you have
...
   not.  It is recommended and simpler to add the new year to all files
   in the package, and be done with it for the rest of the year.
 
 This answers it, doesn't it?

Indeed it does.  My apologies for missing that paragraph.

  - does lilypond follow the GNU maintainers' guide?
 
 I hope so.  If we don't, we should access our working routines.

I don't think we discuss the copyright range format in our
README.txt, so that's one instance in which we don't follow it.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 3.0?

[Graham Percival]

On Thu, Jan 09, 2014 at 12:07:07PM +0100, Urs Liska wrote:
 But it would probably make it more attractive for the consumer
 market if it had a nice default GUI. I personally would be pleased
 to see Frescobaldi become such a default GUI (of course not cutting
 out other options). Particularly given the prospect of Frescobaldi
 providing graphical editing capabilities soon (and provided we'll
 get the Mac OSX installation sorted out).
 
 Would such a step be _conceptually_ acceptable or should LilyPond
 remain GUI-agnostic?

I don't think that such a step would be conceptually acceptable
(we could always provide a stripped down binary package without
the editor).  However, cross-compiling and distributing
Frescobaldi would be a huge undertaking.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Run grand-replace to update copyright

[Graham Percival]

On Sun, Jan 05, 2014 at 09:37:30AM +0100, Werner LEMBERG wrote:
 
  The purpose of listing the year is to give an indication of when the
  copyright will expire.
 
 AFAIK, this is not correct.  We have to make a distinction between
 singular files and files that a part of a package.  What matters for
 us is the *package* copyright.

I do not believe that there is a notion of package copyright in
most countries' laws.  But at this point, I'd like to propose a
distinction between (at least) two questions:

- does the GNU maintainers' guide make suggestions that are
  founded in good legal understanding?

- does lilypond follow the GNU maintainers' guide?

I am reasonably confident that GNU organization consulted with
lawyers as necessary to produce a good set of guidelines.
Admittely the focus would likely be on US copyright law, but I'm
still confident that GNU considered the international situation as
well.  However, it is always possible that somebody made a
mistake, or that the guide is difficult to understand.  In such
case, I suggest contacting GNU directly.

I think the second question is of more immediate concern for
lilypond.  If we don't follow the legal guidelines proposed by
GNU, then we're in a much weaker position if any problems occur.

 If this silent agreement gets ever violated, we have to follow
 standard FSF procedures (since lilypond is an official GNU package),
 asking all contributors to sign copyright assignments to the FSF,
 which would be extremely tedious...

Official GNU packages are not required to sign copyright to the
FSF (that's in the guidelines), but they are encouraged to do so.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: License of files in Documentation/pictures and ability to distribute them unclear

[Graham Percival]

On Fri, Jan 03, 2014 at 03:28:22PM -0800, Don Armstrong wrote:
 There are a lot of files in Documentation/pictures which have no clear
 license, and unfortunately, the git log for them isn't clear at all
 either.

Indeed; those should be clarified.

 Some of them cannot be distributed by lilypond either, for example,
 logo-debian.png is the Debian Restricted Use Logo.[1]

Oops.  Yes, we should replace it with the open use logo.
http://www.debian.org/logos/index.en.html

 It's great that a lot of them have the source which they were built from
 present, but there are some which are still missing the source. [For
 example, logo-debian.png can (and probably should) be built directly
 from the SVG[2] at the appropriate size (or just the SVG used).]

Due to our website hosting situation, it would be awkward to build
it directly.  As for SVG, I'm not familiar with browser and
texinfo support.  We still have something like 50% users on
windows; can IE display SVGs yet?  Also, can texinfo 4.13a handle
SVGs?

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Run grand-replace to update copyright

[Graham Percival]

On Sun, Jan 05, 2014 at 08:09:45AM +0100, Werner LEMBERG wrote:
 
  I'm not a lawyer, but the year in a copyright notice is supposed to
  be the year of original publication. If you have a document first
  published in 2012 with a Copyright 2012 notice and you change the
  year to 2014 without making any other changes, [...]
 
 Looks like a mistake in the conversion script.  `2012' should be
 changed to `2012-2014', of course.

GNU maintainer's guide discourages that:
http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices

However, it's also true that the guide says that copyright numbers
should only be updated if there's a nontrivial change to the
file.  That's different from past lilypond policy.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Run grand-replace to update copyright

[Graham Percival]

On Sun, Jan 05, 2014 at 08:42:59AM +0100, Werner LEMBERG wrote:
 
  Looks like a mistake in the conversion script.  `2012' should be
  changed to `2012-2014', of course.
  
  GNU maintainer's guide discourages that:
  http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices
 
 What exactly does it discourage?

Perhaps discourage is too strong a term:

You can use a range (‘2008-2010’) instead of listing individual
years (‘2008, 2009, 2010’) if and only if: 1) every year in the
range, inclusive, really is a “copyrightable” year that would be
listed individually; and 2) you make an explicit statement in a
README file about this usage.

  However, it's also true that the guide says that copyright numbers
  should only be updated if there's a nontrivial change to the
  file.
 
 You've misread, I think: The guide doesn't say `file' but `package'.
 In general, this means that the copyright of *all* files of the
 LilyPond package[*] should be updated.

I don't get the same impression from that page.  It begins by
saying You should maintain a proper copyright notice and a
license notice in each nontrivial file in the package.

 [*] However, not all files distributed with lilypond are also part of
 the package, cf. `texinfo.tex' or `mf2pt1.mp'.

Indeed.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Content of Introduction-Our Goal

[Graham Percival]

On Wed, Jan 01, 2014 at 06:03:01PM +0100, Urs Liska wrote:
 I see the need to modify the Our Goal box on Introduction, but I
 wouldn't want to do that on my own because it would feel like
 modifying someone else's tune instead of only adding a figured bass
 to it.

I have no objection to any of the changes suggested by you, Phil,
and Carl.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: contributing instructions are misleading!

[Graham Percival]

On Wed, Jan 01, 2014 at 07:45:15PM +, James wrote:
 If you are comfortable with making patches and compiling, LilyDev is
 probably not for you. If you are not or want a ready-to-go
 environment and don't care that it's on some 'old' Linux release
 (i.e. not new and shiny) then LilyDev is perfectly fine.

Agreed.  Urs: if you didn't get that impression from reading the
CG, then could you suggest somewhere to add something to that
effect (or maybe just copy James' comment literally) ?  We don't
actually want to discourage experienced linux users from using
their native environment; like you, I would find it a bit
insulting if a project really did claim that I wasn't able to set
up my own devel environment.  That said, we want to make it
absolutely clear that sorting out the potentially-complicated
build dependencies is not *required* from contributors.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: contributing instructions are misleading!

[Graham Percival]

On Wed, Jan 01, 2014 at 03:47:32PM +0100, Janek Warchoł wrote:
 2014/1/1 Graham Percival gra...@percival-music.ca:
  Not quite.  1) is obvious, but equally important is 1.5) update
  incorrect info.  Remember this latest iteration of interest in the
  CG happened because one or two new contributors tried to follow
  the published (incorrect) info, got into trouble, and
  understandably were irritated.
 
 You're right that updating incorrect info is important.  However, as
 far as i remember there's not much _incorrect_ info left - the problem
 that we have now is more that the information is confusing:
 duplicated, placed in unexpected places, etc.

We rarely (if ever) have perfectly duplicated material.  We tend
to have duplicated and slightly different material.  In such
cases, at least one of the duplications contains incorrect info.

... I'll admit that 10 minutes of poking around in the CG didn't
find any such instances of duplicated material.  CG 1.4 Mentors
should be removed, and most of the stuff in CG 14 Administrative
policies is probably useless and/or misleading, but I didn't see
any obvious huge holes in those 10 minutes.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Images on Introduction and Features

[Graham Percival]

On Fri, Jan 03, 2014 at 02:49:35PM +0100, u...@openlilylib.org wrote:
 
 The images in the first text boxes on Introduction and Features
 are the same. Is there any specific reason for this?

nah, I was just copying material from the old website to the new
website.  It makes sense to use different images.

 IMHO the 'flat-design.png' is much more suitable for Features. On
 Introduction we're talking about freeing from the details of
 layout, and it's somewhat contradictory to display an image beside
 that which *is* about tiny details.

I slightly disagree there; showing that we have a mathematical
representation of the tiny details *does* mean that humans are
freed from dealing with it (since computers can do it).  But I
agree that might not be an obvious conclusion for non-programmers,
so I have no objection to using a different image there.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: contributing instructions are misleading!

[Graham Percival]

On Tue, Dec 31, 2013 at 06:35:36PM +0100, Janek Warchoł wrote:
 2013/12/12 Graham Percival gra...@percival-music.ca:
  Sorry, this awoke Grumpy Graham.
 
 I should have expected that.

Yes, you should have.  :P   Happy new year, BTW.

 Anyway, there are two parts to this cg cleanup:
 1) removing obsolete info
 2) reorganizing things.

Not quite.  1) is obvious, but equally important is 1.5) update
incorrect info.  Remember this latest iteration of interest in the
CG happened because one or two new contributors tried to follow
the published (incorrect) info, got into trouble, and
understandably were irritated.

Reorganizing is a seductively easy thing to propose, but it's
dangerous.  It's easy to have opinions about how things should be
structured, so it's a huge bike-shed debate.  Any proposal to
change the chapters and sections in the CG will involve at least
two weeks of debate on -devel.  Can you honestly say that another
argument like that would not reduce your motivation?  It would be
a shame if a bunch of good suggestions got lost (or delayed by a
few months) because they were wrapped up in a reorganization
patch.  Just look at the proposed website changes from a week or
two ago.

As an added bonus, if you make dozens of obviously good updates to
the CG over weeks and months, then people will gradually recognize
you as an authority on the subject.  Then if/when you propose some
reorganizations, they'll be less skeptical.

  More thinking and discussion than we had the previous 4 times we
  reorganized the CG?
 
 Quite frankly, i'm pretty sure that i gave CG more thought than all of
 us combined since Waltrop 2012 ;-)

and before Waltrop, I spent 100x more timeeffort on the CG than
you did.  Your point?

 Also, times change and stuff like CG gets out of date - even if it was
 ok after previous reorganization, it doesn't mean that a new
 reorganization isn't warranted, don't you think?

Not really.  We still have contributors who need encouragement and
an overview of development.  We still (I think) have lilydev, and
that's still (I think) no easier way to get started.  We still
have documentation, a website, programming in C++ and scheme, etc.

Granted, the previous plans about having mentors fell apart, so
those parts of the CG should be removed.  But other than that, I
think a reorganization would mostly be a distraction away from
fixing incorrect info.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: CG organization (Git)

[Graham Percival]

On Sun, Dec 22, 2013 at 09:55:39AM +0100, Urs Liska wrote:
 I'm somewhat confused about the organization of the CG chapters
 about Git and patch review.
 
 First:
 3.2.2 Git for the impatient and
 3.3 Basic Git procedures
 
 share some information, and this in a somewhat confusing way.
 Is there a _short_ explanation what these two chapters are intended for?

3.2.2 was added more recently than 3.3, and was supposed to be a
no fluff approach to git.  Some people like more or less verbose
explanations of what's happening.

IMO, neither of these sections should be read by newbies, but I
think that relied on the assumption that a mentor would be
available.  Without a mentor, we add 10+ hours to a new
contributor's first patch (unless the contributor has previous
experience with open-source projects).

 Second:
 3.2. seems to be targeted at absolute beginners.
 So why does it explain the workflow with pushing to staging?
 Anybody who needs to read this chapter won't have commit access.

Most of 3.2 was written before we had staging, and I think it was
even before we had lily-git.tcl.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: CG organization (Git)

[Graham Percival]

On Sun, Dec 22, 2013 at 10:40:04AM +0100, Urs Liska wrote:
  After a good deal of thinking, here's how i think CG should be
  structured.
  More thinking and discussion than we had the previous 4 times we
  reorganized the CG?
 from a week ago.

Chapters 1 and 2 are solid (other than the bits about mentors, and
possibly being out of date with respect to lilydev).

The rest of the CG has decent chapters, but the material within
each chapter is a mess.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Mon, Dec 16, 2013 at 01:50:53PM -0500, Carl Peterson wrote:
 (2) utilizing back-end scripting (PHP, etc.) to custom-serve the
 content based on the http header.

We're using a donated web-server, and don't have root access.
When (not if) PHP has another security hole, I don't think we want
us to be responsible for somebody else's server getting hosed.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Mon, Dec 16, 2013 at 01:27:05PM +0100, David Kastrup wrote:
 Maybe interactive is a useful term?  Like
 
 LilyPond is not an interactive program: its sole task is translating
 a textual description of music into typeset music.  For creating that
 textual description, an editor is required.
 
 While any general-purpose text editor can be used for this task, some
 applications are specifically tailored to working with LilyPond.
 
 Yes, this is getting verbose again, but it's likely hard to whittle it
 down significantly.  At any rate, it might be a starting point regarding
 the concepts and information we need to convey.

Three sentences is sufficently succinct, IMO.  I have no problem
with a patch that changed the download warning macro into this.
(although the above would need to be reworded slightly to
accommodate the @refs{})

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fwd: Re: Website improvements, part 1

[Graham Percival]

On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote:
 Am 12.12.2013 04:19, schrieb Graham Percival:
 ok.  I also like the applicances tab, although I agree with you
 that the name might be ideal (but I also can't think of a better
 name right now).
 
 Just a bunch of ideas:
 We're talking about
 - Applications of LilyPond
 - Use of LilyPond in different contexts
 - Abusing LiylPond
 - integrating LilyPond in other tools
 - making LilyPond part of something else
 - using LilyPond as an engine for other tools
 
 Does this trigger any ideas for a menu/page title with anybody?

If this was aimed at programmers, I'd be tempted to call it
Integration or Library, but those would not be clear to 95%+
of people reading the introduction.  Hmm... I have a slight
preference for applications rather than appliances; as a
native speaker, I think appliances as being things like the
fridges, ovens, or washing machines.

 IMO examples should remain part of that.
 
 Any more opinions on that?
 My reasoning was:
 - I think Features-Background-Freedom and then
   How LilyPond works
   is a good reading path
 - Examples is similar to a Screenshots menu item in many websites
   and can be somewhat taken out of that intitial reading path

Yes and no... I totally agree that Examples is similar to
screenshots, but when we're talking about music engraving, the
quality of engraving (and flexibility / range of supported
notation) is an essential feature.  The only reason I didn't put
examples and features together was that I wanted to have a tab
called examples for additional visibility; some readers might
not realize that features included examples if I put them
together.

I mean, if you're talking about why use lilypond?, then IMO the
examples are the most important part.  Freedom matters to some
people but not others, and IMO the background is almost completely
irrelevant.

 If anything, I think that the web frontends should get their own
 tab.
 
 You mean the box from Editing should be raised to its own page,
 next to Editing?

Yes.

 The general design of the website is to
 go top-left, top-right, bottom-left, bottom-right.  I'm not
 certain this is an important distinction, but it's worth
 considering.
 
 OK, I considered it by clicking through the complete website (except
 the docs of course) and saw that there isn't any single comparable
 case.
 Usually when we have two boxes side by side they are followed by a
 column-center box, so the flow is clear.

True.  Could we retain the flow in a similar way?  Do we need 4
divs, or could we still only have 3?


 So what to do with it?
 Semantically it would be less ambiguous to use only one column for
 the Introduction page.
 But that wouldn't look nice because the items are so short.
 I could accept changing this order (i.e. exchange the boxes
 right-top and bottom-left), but I wouldn't consider it necessary -
 the ambiguity should be suitable for that page.

I'm still not wild about this optional flow.  The original pages
were aimed at:
- info 1.
  Decided you want lilypond?  goto text input.  Not decided go next.
- info 2.
  Decided you want lilypond?  goto text input.  Not decided go next.
- info 3.
  Decided you want lilypond?  goto text input.  Not decided go next.
- info 4.
... etc.

The whole goal is to funnel people towards text input so they
get the warnings about lilypond.  Either people aren't reaching
text input, or the warnings on that page aren't sufficiently
clear.

I think that's a more clear flow than the proposed change.

 The incentive for reviewing of the website structure was (on
 lilypond-user) that too many people don't realize the basics of the
 compiled approach when visiting the website.

See other thread for clarifying text input.

 More involved changes that I could nevertheless put up for review?
 - Rename Easier Editing to Editing
   (does this affect translation more than other changes?)

Probably, but that's why it's even more important to present that
as an independent change.

 - Updating the Editing page
   (split in two parts: reorganisation of items / rewording)
 - Rewrite of the Features page

I'd include adding a new page for web apps in the list of small,
independent patches that should go forward.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Sun, Dec 15, 2013 at 07:48:28PM +0100, David Kastrup wrote:
 Urs Liska u...@openlilylib.org writes:
 
  But it's actually quite off-putting when you prepare a patch that is
  more or less based on a broad (and astonishingly productive)
  discussion on lilypond-user, and then (after two steps of fine-tuning)
  someone steps out and asks why are you doing this?. (This is not
  personal against Graham because I know next it might be someone else.)
 
 Yes.  It is a major part of review processes that
 
 a) some people come late into the game
 b) the preceding discussion on the user list is isolated from the actual
patch review process.

I want to emphasize these points.  The whole review process was
put into place to encourage the senior developers to stick around
and at least give comments on patches.  There's still a ton of
design decisions that are only known to the people who originally
wrote that code or document.  The goal is to allow  encourage
those people (which I guess include me now) to pass along reasons
why they made the decisions they did.

If patches were accepted and pushed within a day, the senior devs
might not have a chance to reply, and then give up on providing
any input at all.  Having a patch countdown of 48 hours or more,
with no penalty for people coming late to the discussion
(provided it's still within 48 hours), is a trade-off of
encouraging senior devs to comment vs. encouraging new developers
to make lots of changes.

Of course, I'm not clamining that the design decisions of previous
developers are necessarily correct.  Maybe after discussing it
with them, the community decides that it's worth breaking the
previous architecture plan.  But I think that discussion is well
worth having.

  I don't want to imagine what happens if I propose my rewrite of the
  Features page (http://www.openlilylib.org/lilyweb/features.html).

A rewrite of a single page has less impact than changing the
intended flow of a new reader through the website.  My only
problem with your proposed Features page is that it changes the
flow (i.e. the where now? box at the bottom).  If you changed it
back to the original where now? box, I'd have no problem with
that new Features page.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Mon, Dec 16, 2013 at 11:29:44AM +0800, Graham Percival wrote:
  Urs Liska u...@openlilylib.org writes:
   I don't want to imagine what happens if I propose my rewrite of the
   Features page (http://www.openlilylib.org/lilyweb/features.html).
 
 A rewrite of a single page has less impact than changing the
 intended flow of a new reader through the website.  My only
 problem with your proposed Features page is that it changes the
 flow (i.e. the where now? box at the bottom).  If you changed it
 back to the original where now? box, I'd have no problem with
 that new Features page.

Oops, there is one problem with that new Features page.  You
wrote:
  Read more on the _Community_ pages.
with the link on _Community_.  This is not encouraged with
texinfo, because that _Community_ link will be hard to read in the
pdf version.  Instead, please reword the sentence so that the link
is at the end of the sentence (as you've done everywhere else on
that page).

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Sun, Dec 15, 2013 at 01:23:51PM +0100, Urs Liska wrote:
 Am 15.12.2013 06:47, schrieb Graham Percival:
 2) they noticed the existing, read the text input page, but were
 still confused.  Solution: improve the text input page.
 
 I think the only issue with text input might be that it isn't
 explicit (or rather suggestive) enough about the editing
 environment.

Then it should be fixed.

 Was it clear from the discussion on -user which of those problems
 it was?
 
 Not unambiguously clear. But it seems clear that we will have to
 take into account that people will proceed directly to the Download
 page without reading anything of the introduction or the Features
 page at most.

Hence the warning.

 Maybe another whole page about sample
 usage, or something like that?
 
 Maybe this should even be split: One dedicated page explaining the
 concept of IDEs, similar to the Text Input page but less elaborate,
 and another page that more or less lists available editors (i.e. the
 current Easier editing page with some modifications).

I like that idea.  So there would be 3 pages in Introduction:
- lilypond is text input
- text input means you write text
- list of available editors


 It was consensus that new users should actively be encouraged to
 download one of the complete environments, namely Frescobaldi or
 Denemo, which would then take care of installing LilyPond.

Is Frescobaldi available on OSX?  It's lacking the appropriate
symbol on the easier-editing page.
... apparently it's only available in macports.  That isn't
something that we should ask most users to try.

Denemo is not available on FreeBSD or OSX (accoring to the
symbols) so we can't recommend it without deliberately ignoring
some users.  Granted, anybody using freebsd will already know how
things work, but we shouldn't ignore OSX users, particularly since
many composers prefer OSX.

 I think the considerations about chattiness of texts or redundancy
 of information are suitable and necessary for the docs, but much
 less for the website.

I think that suitable chattiness is even *more* important for the
website.  Adding text is the easiest thing to do to docs, but can
often make users turn off their brains and not read stuff.  My
rule of thumb is that doubling the text results in half the number
of people reading it.

 The website doesn't have to be redundancy-free document with every
 information exactly once and in the right place (which it is far
 from currently BTW). It should rather be a comfortable place for
 potential new users who aren't already familiar with LilyPond or
 text based toolchains in general.

Right.  So let's direct new users to the best explanation we have
for how lilypond works.  Not a 3-sentence summary of the
situation.  Direct them to a whole page with images, examples,
screenshots, video screencasts, embedded youtube videos, etc.
If somebody is unfamiliar with text input, you cannot give a good
explanation in 3 sentences that they will understand.  You can't,
I can't, nobody can.  It's a whole different concept.

Sure, we could add 3 pages of material to the top of the download
page (and presumably the top of the Windows download page as
well).  But that would annoy experienced users.  Solution: use a
short notice to get newbies onto a dedicated page for them.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Mon, Dec 16, 2013 at 07:53:38AM +0100, David Kastrup wrote:
  Note: LilyPond is a text-based music engraver; it is more similar to a
  programming language than a graphical score editing program. Before
  downloading LilyPond, please read about our Text input. 
 
 Which is not helping much.  It prepares me for an IDE like Visual C++
 or, uh, Frescobaldi.

 Not for a command line application.

But surely programming language means edit with vim, compile
with make.  ;)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Mon, Dec 16, 2013 at 12:42:16AM -0500, Carl Peterson wrote:
Just thinking out loud here...would it be worth looking into tweaking the
.htaccess file to do OS-based redirection on the download page, like many
sites do?

That's possible, but having the unified landing page lets us
include the software license, sponsors, and pointers to source
code, old downloads, and devel versions.  We could add those to
all the individual pages, of course, but I don't think it's worth
changing that much.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Web: Download: Add introductory text (issue 40510046)

[Graham Percival]

On Sat, Dec 14, 2013 at 09:46:54AM +, lilyli...@googlemail.com wrote:
 
 On 2013/12/14 03:51:33, Graham Percival wrote:
 Umm, isn't the whole point of this to be a warning?  Why are you
 removing the
 warning CSS tag?
 
 It's the whole point of this patch to raise this information to the
 level of regular website text.

Why?  So that it's not as obvious?  I imagine two situations in
which people download the binary without knowing what they're
getting.

1) they didn't notice the existing warning.  Solution: change the
CSS to make it more prominent.

2) they noticed the existing, read the text input page, but were
still confused.  Solution: improve the text input page.

Was it clear from the discussion on -user which of those problems
it was?

 From discussion in several quite diversified threads on lilypond-user it
 became clear that people (i.e. potential new users) have to get a
 clearer picture of what LilyPond and its infrastructure essentially are.
 This was the whole idea of starting a website review.

Ok.  That should be done in the introduction.  Maybe more images
on the Text input page?  Maybe another whole page about sample
usage, or something like that?

... wait a moment, doesn't the Windows download page include
screenshots of how to use the lilypond binary?  Did people fail to
notice those screenshots?

 I don't think making the Note more visible will help with the fact
 that people reaching the homepage, then click on Download get the
 right picture from it. I think a regular box with Before you proceed
 and the second stopper You just wnat a new version? will be more
 effective than a warning box.

I'm fine with rewording the warning box.  Text like before you
proceed might be good.  However, I'm *not* fine with reproducing
a bunch of explanations about how lilypond works.  We have a place
to explain that: the introduction.  Either people aren't finding
Text input, or Text input needs work.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)

[Graham Percival]

On Fri, Dec 13, 2013 at 10:02:23AM -0500, Carl Peterson wrote:
 On Thu, Dec 12, 2013 at 7:36 PM,  carl.d.soren...@gmail.com wrote:
  I think that the index sidebar colors are too dark.  They dominate the
  page, in my opinon.  In the current design, the sidebar color and the
  highlight box fill color are the same.  Why not keep it that way?
 
 Attaching another option, to address your concern, as well as
 Graham's.

Yes, much better!

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website questions: GSoC

[Graham Percival]

On Thu, Dec 12, 2013 at 02:06:38PM +0100, Urs Liska wrote:
 The page GSoC 2012 is obviously outdated.
 
 What should be done with it?

I suggest deleting it.  There's no evidence that the proposed
mentors are still available or interested, and those specific
proposals are a small subject of the available issues in the
tracker.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website questions: Manual-Web

[Graham Percival]

On Thu, Dec 12, 2013 at 09:34:28PM +0100, Urs Liska wrote:
 When I go there I can download the whole website as a PDF. OK, this
 makes sense.
 Getting it as one big HTML page also makes sense.
 [but where can I get it in info format?)

We don't provide links to the info documents, because IMO none of
them have any images built-in.  info+images only happens through a
proper make install, so that's not something we can offer on the
website.

 But clicking on Web (split HTML) brings you to a copy of the whole
 website, just several directories below the original.

I suppose we could hide that part in an @ifnothtml.

 If this page is there for the first two items I mentioned the text
 in the left box should definitely be clarified. Currently this
 manual leads the reader to believe that he gets yet one more
 manual, with some general information.

I wouldn't object to having a few sentences added to that box.

 And there is one more thing I stumbled over (although I don't find
 an instance of it right now): There are links from within the real
 manuals that seem to link to the website but actually point to that
 web manual (i.e. pages below lilypond.org/doc/2.17/web).

Unavoidable without a great deal of knowledge about the doc build
system and quite possibly GUB as well.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website questions: Manual-Web

[Graham Percival]

On Fri, Dec 13, 2013 at 03:40:03PM -, Phil Holmes wrote:
 I _think_ the odd place of web in the manuals hierarchy is down to
 it being the only part of the documentation that built using make
 website - it has something of a split personality between being
 part of the documentation and the website.

No, there's three separate issues here.

- lilypond.org/web/ : the old website
- lilypond.org/website/ : the thing built with make website,
  with an .htaccess to make /website/foo.html appear as /foo.html
- the documentation, which includes web.texi, and thus appears as
  lilypond.org/doc/v2.17/website/  (I think, didn't check that url)

If we don't build web.texi within a normal doc build, then various
@ref{}s would fail, and the pdf-only and info-only docs would have
broken links.  Also, come to think of it, a local installation of
the html files would also have broken links.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)

[Graham Percival]

On Thu, Dec 12, 2013 at 05:58:33PM -0500, Carl Peterson wrote:
For those who need a visual of these changes, I've uploaded screenshots to
the Google Code issue.
https://code.google.com/p/lilypond/issues/detail?id=3714.

Woah, why are you changing the whole background?  It looks a bit
cartoony.  I would suggest only changing the sidebar and possibly
header, not anything in the main doc pages.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: contributing instructions are misleading!

[Graham Percival]

On Wed, Dec 11, 2013 at 01:48:54PM +0100, Janek Warchoł wrote:
 PS ccing to Graham because he might be interested to know that
 Someone(TM) is doing Something(TM) to help new contributors!

Sorry, this awoke Grumpy Graham.

Reorganizing the CG is very much a something should be done, this
is something, so can somebody else do this thing.

 After a good deal of thinking, here's how i think CG should be
 structured.

More thinking and discussion than we had the previous 4 times we
reorganized the CG?

 The first chapter should contain everything that a
 contributor should know

... so chapter 1 will be 50 pages?

 (including ho to upload patches for review), and if possible it
 shouldn't contain optional information (for example not everyone
 needs to use LilyDev, so this should be in a separate chapter).

Is there any solid evidence that a serious contributor finds it
difficult to skip over section 2.1 if it's not relevant?

 1) Introduction and Quick start
* setting up development environment
  - link to Lilydev
  - env variables
  - Initializing a repository
  - installing git-cl
  - git setup tips (i.e. showing branch in prompt)

But new developers don't need to know anything in there, other
than the link to lilydev.  Lilydev and git-cl handle everything
else.  So your goal of everything that a contributor should know
and shouldn't contain optional information already failed.


I agree that it's really bad that the CG encouraged people to send
stuff to the Frogs list.  A fix for that was certainly needed.
That doesn't imply that yet another round of reorganizing the CG
is needed.  It would be much more useful to go through the CG and
update the content as necessary.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website improvements, part 1

[Graham Percival]

On Wed, Dec 11, 2013 at 02:21:28PM +0100, Urs Liska wrote:
- I changed Easier editing to Editing.

ok.  I also like the applicances tab, although I agree with you
that the name might be ideal (but I also can't think of a better
name right now).

- I organized the entry scenario (= introduction.html) according to three
questions
  - Why should I consider LilyPond?

IMO examples should remain part of that.

  - Does it really work/what's the real-world use?

I'd be fine with calling that box LilyPond in the real world,
although I'm not certain if the applicances should be in this
category.  I mean, some of them make sense (like wikipedia), but
others seem like toy examples.

If anything, I think that the web frontends should get their own
tab.

  This is reflected in the layout of the boxes on introduction.html
  while it's irrelevant in which direction the user proceeds from the
Why box

At the moment, the order seems to go top-left, bottom-left,
top-right, bottom-right.  The general design of the website is to
go top-left, top-right, bottom-left, bottom-right.  I'm not
certain this is an important distinction, but it's worth
considering.  However, I still think that text input and editing
should be the final part of the introduction.

- I think it would be good to add something about version control on the
  Text input page, but that's something I wouldn't want to do without
  prior discussion.

I disagree.  The purpose of text input is to make potential
users realize that yes, we use text, but no, it's not too
complicated.  Version control is a complicated concept for
non-programmers which would dilute the previous message.  You
already mentioned version control on the Features page, which
should be sufficient.

- I think the @contactUsAbout macro should be reconsidered.

I agree, you made good points here.

Please note that *this* is the kind of change that can be done
immediately, submitted for review, etc.  It doesn't need to wait
for James to finish his changes or 2.18 to be released.  I would
*heavily* encourage you to submit small improvements like this
soon, instead of combining them in a large reorganization that
creates havoc for translators.

Apart from the technical impact on the doc system, making small
changes like this reassure developers that you're serious and that
you know how the system works.

- The structure of the Community section is, ehm, wild.
  I think it would be good to have an additional navigational layer.
  But before thinking about a structure I'd like to know if this would be
accepted.

Probably not.  There's @chapters and @sections; having a bunch of
@subsections for one chapter is a bit weird.

I agree that Community is a bit wild; can you think of a division
that would split it into two chapters?

- I have one question about the structure of Manuals:
  What the hell is this Web menu item for?

The website.  It's created as a pdf and info.  One of the very
early goals of the doc system is that all the information should
be present via only info or pdfs (i.e. without an internet
connection).

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: contributing instructions are misleading!

[Graham Percival]

On Wed, Dec 11, 2013 at 10:20:22PM -0500, Carl Peterson wrote:
 I was able to connect to git with minimal fuss, and currently
 use the lily-git.tcl tool to handle commits and patches.

Great!  This suggests that the introduction in the CG is ok.

All that said, where things got interesting for me was when I wanted to
figure out how to submit my patch. Following through the directions in 2.2
(lily-git), I got to this text:
 Send patch files to the appropriate place:

 * If you have a mentor, send it to them via email.
 * New contributors should send the patch attached to an email to
fr...@lilynet.net. Please add a**[PATCH]a** to the subject line.
 * Translators should send patches to translati...@lilynet.net.
 * More experienced contributors should upload the patch for web-based

Right.  From memory, I think there's 3 different sets of
instructions for submitting a patch in the CG.  2 of them contain
factually incorrect information, and 1 of them was correct as of
summer 2012.  That one is probably still correct, but I wouldn't
feel comfortable vounching for it.

Fixing this doesn't require a reorganization.  It requires
deleting the two incorrect bits, dumping a @ref{Submitting a
patch} or whatever the @node is called.  On a similar note,
there's at least 2 checklists before submitting a patch, at
least 1 of which has obsolete info.

... come to think of it, the whole mentor infrastructure never
got off the ground, so there *is* misleading info in chapter 1.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: contributing instructions are misleading!

[Graham Percival]

On Wed, Dec 11, 2013 at 11:26:55PM -0500, Carl Peterson wrote:
In my searching, I didn't find a page that really did this. Section 1.2 of
the current CG should theoretically do this (based on the title), but it
mostly just talks philosophically about git.

Sounds good.  I've never liked that wall of text in CG 1.2.  How
about you rename the existing section to something like
Introduction to open-source development or Introduction to
git, then add a new section that's the kind of overview you
suggested.

NB: this type of change is minimally invasive, has a well-defined
scope, and can be done in an hour without requiring lots of
discussion on -devel.  By contrast, based on historical evidence,
any discussion about reorganizing any document is likely to
involve at least 5 hours of emails and has over a 50% chance of
somebody's feelings getting hurt.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: branching

[Graham Percival]

On Tue, Dec 10, 2013 at 02:42:45PM +0200, Mike Solomon wrote:
 On the website, we would offer _all_ of these development
 branches, including the one built off of staging, as GUB builds.

A few years ago, we were asked to cut our downloads down to 5 GB.
I deleted a bunch of devel stuff and got it down to 7 or 8, but
we're probably back to 15 GB now.  I don't think we should fill up
the server with that many builds, nor do I think we should ask
James to do all that building.

 We would also contain a tracker showing number of downloads and
 encouraging users to download the branches that have been
 downloaded the _least_.

I don't like the idea of treating users as guinea pigs.  If
somebody wants to test out devel stuff, it's not unreasonable for
them to compile it themselves (inside lilydev if necessary).

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: branching

[Graham Percival]

On Tue, Dec 10, 2013 at 04:30:32PM +0200, Mike Solomon wrote:
 
 (quotes from David)
 
 The basic idea behind that is not to make confrontations nicer but
 reduce the necessity for them by establishing playing fields with
 different authorities.  So that people can get work done without
 endangering the release, and I can get releases done without pissing
 people off as a prerequisite.

I agree with this idea, but I feel like I'm missing something.
How would regular git branches be insufficient for this?  Is it
simply the lack of GUB for branches?

I mean, is the problem a technical or social one?  My gut feeling
is that this is a social issue, so any technical wish-lists are a
red herring.  That said, I admit that I haven't even skimmed the
patch countdowns in the past few months, let alone read any
arguments on -devel.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

centralization of lilypond development and forking (was: branching)

[Graham Percival]

On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote:
See:

 http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870
as one of several examples.  There is truth in anything David says,
meaning that I (like him (and most of us on this list)) have caused bugs
that I did not find or fix before someone else.  How, does this warrant
this communication style?

Interesting.  I totally agree that lilypond has a problem (see
below), but in that email chain I find myself nodding along with
David.  I mean, he makes empirical claims (such as documentation
about partial elliptic stencils) that I assume are accurate (since
I doubt he would make empirical claims without checking that they
are true).


However, I am not blind to the end result of the communications.
I mean, at the beginning of September 2012 (after the meeting at
the ranch) I was more enthusiastic about LilyPond than I had been
for the previous 5 years, but one month later I decided to pretty
much quit the project.

I know I have the (well-deserved) reputation of being extremely
conservative, but that's in part because I don't want to abuse any
donations or make any demands on existing/previous volunteers.
The idea of providing multiple binaries is one such example
(donated web serving and bandwidth), and the general notion of
lilypond should not break stuff that previously deliberately
worked is another.

But that's not to say that those constraints are unbreakable.  The
usual approach in the open-source community to a situation where a
significant number of people want to have a radical break with
previous traditions is to fork the project.

As a thought experiment, let's suppose that a new project forks
from 2.18.0, called OakMountain instead of LilyPond.  At a bare
minimum, OakMountain would need:
- a git repository.  (trivially easy these days)
- does it want to provide binaries?  Using GUB would bring in a
  huge amount of technical constraints, along with a certain
  amount of bandwidth required.  But maybe OakMountain wouldn't
  care about that; it could target linux only, and provide an
  Ubuntu disk image for any users on windows or OSX who want to do
  engraving.
  (admittedly, the Ubuntu image would also require a fair chunk of
  bandwidth... but maybe OakMountain would target the default
  Ubuntu 12.04 live disk image)
- does it want to provide any defence against regressions?  Maybe
  not.  Maybe OakMountain would guarantee that monophonic music
  with no lyrics will still work, but anything else could change
  and break.


This is not a rhetorical question.  I'm still quite interested in
having a music engraving system that's suitable for a final
version of my string music scores (particularly in conjuction
with Vivi, physical modelling performances of those works).  As we
saw in Sep 2012, LilyPond does not qualify, but if this was a goal
of OakMountain then I'd be interested in joining.
(that said, I'm contractually forbidden from contributing code to
open-source projects until June 2014, although emails and
organization are fine)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reasoning behind convert-ly rule for stable update?

[Graham Percival]

On Sun, Nov 24, 2013 at 06:12:16PM +0100, David Kastrup wrote:
 
 Does anybody know _why_ convert-ly updates at least to the last stable
 version number even if nothing else has been changed?

Yes, because it's confusing for some users if they've downloaded
the latest and greatest lilypond 2.18.0, run convert-ly, and see
that their files are 2.17.37.  If you check the git history on
convert-ly or convert-rules, then check the mailing list archives
from a few days before then, you'll see the discussion.  Or this
might even be in the issue tracker.

Also, when dealing with large collections of files, it's
reassuring that the files really are current as-of 2.x.0.  I mean,
if I see input/regression/foo.ly being 2.13.5, does that mean that
people forgot to run convert-ly, or does it mean that it really
has no syntax changes since then?

 But for another, it loses significant information.  Is there some way we
 can retain this information?

I don't think that's useful info, but I suppose that there's
little harm in adding an option to convert-ly which writes a
comment with the previous revision.  It shouldn't be the default
behaviour, though.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

[Graham Percival]

On Mon, Sep 30, 2013 at 12:26:13AM +0200, Eluze wrote:
 
 but weeks ago I already told how unfair this system is: Phil's
 releases happen on week-ends usually and then it's my turn - the
 others rarely get the opportunity to get accustomed to verifying.

Well, if everybody strictly does no more than X minutes on their
day, then the load would be spread out more evenly.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

[Graham Percival]

On Sun, Sep 29, 2013 at 09:49:07PM +0100, Phil Holmes wrote:
 - Original Message - From: David Kastrup d...@gnu.org
 It matches the theory.  In practice, I've been startled quite a few
 times when bug squad members not just verified the commit to be present
 but also reported back when it turned out that the claimed functionality
 did not actually accompany the commit.

Well, it's nice to have pleasant surprises?  :)

 Graham and I used to debate this.  His view was that all that is
 required of Bug Squad members is to verify that a claimed fix was
 committed.

Don't forget that using the issue tracker for patch submission is
a bit of a hack.  It was added because we were losing too many
patches.

If an issue is actual bug report, i.e. contains a minimal example,
then of course the bug squad member should check that the minimal
example no longer produces the flawed graphical output.  I just
don't think it's worth inventing a lot of extra work for
patch-only issues.

 I do think that claimed fixes to real bugs should have a tiny
 example, and the bug squad should confirm that the tiny example
 no longer fails.  This could argue for a more rigorous approach
 to bug acceptance: no example, no report.

Don't we already have a no example, no report policy for bugs?!
We certainly should.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypad is localized?

[Graham Percival]

On Sat, Sep 28, 2013 at 08:24:13AM +0200, David Kastrup wrote:
 
 So the real question _if_ it is localized is how you can figure out the
 translations used in the localized versions so that you can _copy_ them
 into the documentation and/or put better translations in _both_ places.
 
 Graham?

I have a very vague memory of seeing different language pngs in
Documentation/pictures/, but that's it.  I certainly have no
direct knowledge of windows lilypad.  If there's nothing obvious
in Documentation/pictures/ then I'd just assume there's no
localization.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our contributing tools and workflow

[Graham Percival]

On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote:
 On 26/09/13 14:52, Phil Holmes wrote:
 We've had bad experiences where a helpful and enthusiastic new
 contributor misunderstood the instructions, ran off and did 5 hours of
 work instead of 10 minutes, and none of the main developers wanted to
 take the time to deal with the results of the 5-hour work, so the
 whole thing was wasted. (literally wasted, as in the project would
 have received more benefit from the 10-minute job instead of the
 5-hour work)
 
 This risks becoming another corrosive discussion,

Then WTF are you starting it?

 There is another possible response to such a situation, and it's:
 Oh wow, this person put a load of work in, they're obviously really
 committed and enthusiastic.  OK, let's use these problems with what
 they've done as an opportunity to educate them better about how
 Lilypond works and how to avoid these kinds of problem in the
 future, and make them feel that we really value the time they've put
 in and want to repay them in kind.

Great answer!  I'm so happy that YOU STEPPED FORWARD TO DO THIS IN
THE PAST.  The main developers owe NOTHING to somebody just
because they did some work.  I try to warn people NOT to waste
their time, and Phil helpfully carries these warnings forward, and
people criticize us for being demotivating.

 But I still think that it's possible to approach
 contributors with enthusiastic caution rather than lowered
 expectations, which are demoralizing for everyone.

I breathlessly await the time when YOU do this, instead of
complaining that existing developers don't do whatever you think
they should be doing.  Of course, first you need to learn how
stuff works, and so far you've shown minimal interest in doing so.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel