On 11/25/11 11:46 AM, "Phil Holmes" <m...@philholmes.net> wrote:
>----- Original Message ----- >From: "Carl Sorensen" <c_soren...@byu.edu> >To: "Phil Holmes" <em...@philholmes.net>; "Devel" <lilypond-devel@gnu.org> >Sent: Friday, November 25, 2011 6:35 PM >Subject: Re: LSR updates and Issue 1971 > > >> >> >> On 11/25/11 10:59 AM, "Phil Holmes" <em...@philholmes.net> wrote: >> >>>I've got a large patch that updates the snippets from the LSR and fixes >>>Issue 1971. It's a few hundred files. make and make doc are fine after >>>adding it. Should I push to staging or do something like a review - it >>>seems unlikely anyone will have the enthusiasm to review all 300-odd >>>changed >>>files. >> >> What do you mean by "updates the snippets from the LSR"? Snippets from >> the LSR should be fixed in the LSR. Snippets that can't be the same as >>in >> the LSR (due to changes in the version) should be in >> Documentation/snippets/new. But why are there 300-odd changed files? >> >> More information would certainly be helpful to understand this issue. >> >> Thanks, >> >> Carl > >It's a snippet in snippets/new, since it doesn't run on 2.12. To correct >these, you need to correct the snippet in snippets/new and then run >makelsr >to get the correct version into snippets/. To run makelsr you have to >have >downloaded the latest LSR tarball, and so running the updates on this >causes >them all (I think) to be changed because convert-ly is run. So every >snippet is changed, which makes for a large patch. For this patch, go ahead and push, as long as make doc works. For the future, I think you can run makelsr.py with downloading the latest LSR tarball (at least I have in the past), and that will get the changed snippets into the docs *without* changing all the files. IIUC, as part of the release process for a new version, we ought to do a makelsr.py, which should run convert-ly on the snippets. That commit should be separate from one that requires manual editing of snippets. The makelsr.py-run patch does not require review. Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel