Re: Issue 1392 in lilypond: Internals Reference should document \paper variables
Updates: Labels: -Priority-Medium Comment #3 on issue 1392 by pkx1...@gmail.com: Internals Reference should document \paper variables http://code.google.com/p/lilypond/issues/detail?id=1392 Using (as per Mike's advice) grep "c_variable" and then sort -u I get the following list of paper variables. I don't know if this is comprehensive but it is a start: --snip-- auto-first-page-number binding-offset bottom-margin check-consistency first-page-number footnote-footer-padding footnote-numbering-function footnote-number-raise footnote-padding footnote-separator-markup inner-margin inner-margin-default-scaled is-last-bookpart is-layout is-midi is-paper label-page-table last-bottom-spacing line-width markup-markup-spacing markup-system-spacing max-systems-per-page min-systems-per-page number-footnote-table orphan-penalty outer-margin outer-margin-default-scaled output-scale page-breaking page-breaking-system-system-spacing page-count page-post-process page-spacing-weight paper-height paper-width ragged-bottom ragged-last ragged-last-bottom ragged-right reset-footnotes-on-new-page score-markup-spacing score-system-spacing system-count systems-per-page system-system-spacing top-margin top-markup-spacing top-system-spacing two-sided --snip-- James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2024 in lilypond: Patch: Let #{ ... #} pass its $ handling to environment cloning
Updates:
Labels: Patch-new
Comment #2 on issue 2024 by d...@gnu.org: Patch: Let #{ ... #} pass its $
handling to environment cloning
http://code.google.com/p/lilypond/issues/detail?id=2024#c2
Issue 2024: Let #{ ... #} pass its $ handling to environment cloning
Consists of the patches:
Adapt docs to new $ and #{ ... #} behavior
Run scripts/auxiliar/update-with-convert-ly.sh
Let #{ ... #} pass its $ handling to environment cloning
Includes convertrules.py rules
Permit ly:parser-clone to receive an environment
lexer.ll: add $ for immediate export.
Purpose is to make $ generally available rather than to have it just
in #{ ... #}, let it completely replace the need for ly:export, and to
let #{ ... #} import its lexical environment into its embedded Scheme
expressions via # or $.
Unfortunately, you will likely have to bump PATCHLEVEL in VERSION
manually for testing, as dev/staging is still locked at 2.15.17 which
is too small after running convert-ly.
http://codereview.appspot.com/5341049
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 11 in lilypond: beamlet on wrong side of tuplet sixteenth
Updates: Labels: -Patch-needs_work Patch-new Comment #25 on issue 11 by carl.d.s...@gmail.com: beamlet on wrong side of tuplet sixteenth http://code.google.com/p/lilypond/issues/detail?id=11 New patch set. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Regression in 2.14.2, dynamic cast crash introduced in commit 6f6369c0
Hello!
Lilypond 2.14.2 and the current revision from stable/2.14 crash on this
file:
\version "2.14.2"
\score {
\new PianoStaff <<
\new Staff = "right" { \change Staff="left" }
\new Staff = "left" { s1 }
>>
\layout { }
}
Bisection finds that the regression was introduced on the stable branch
(!!!) by this commit:
6f6369c0e143402296e51708fddb8e3cc875dd09 is the first bad commit
commit 6f6369c0e143402296e51708fddb8e3cc875dd09
Author: Joe Neeman
Date: Fri May 27 18:57:16 2011 +0300
Emit not-quite-cross-staff beams in the right context.
This is related to 1043 and possibly other bugs. Previously,
if a staff change happened immediately after the termination of
an auto-engraved cross-staff beam, then the beam was parented
to the wrong staff. Now, every beam is parented to the context
in which it began.
:04 04 9fb6f0e342f2e64ca9b56c2d6e0d02556895e983
f248a9e0cc58847fddc0ad98e7eb839b8d3dbc60 M lily
And that's what gdb shows for the current stable/2.14:
GNU LilyPond 2.14.2
Processing `bad.ly'
Parsing...
Interpreting music...
Program received signal SIGSEGV, Segmentation fault.
__cxxabiv1::__dynamic_cast (src_ptr=0x7fff, src_type=0xae1870,
dst_type=0xad9ea0, src2dst=-1)
at ../../../../libstdc++-v3/libsupc++/dyncast.cc:51 51const
void *vtable = *static_cast (src_ptr); (gdb) up
#1 0x0054cef4 in Engraver_group::announce_grob (this=0xc8c840,
info=...) at engraver-group.cc:83 83: 0; (gdb) l
78 }
79
80Engraver_group *dad_eng
81 = dad_con
82 ? dynamic_cast (dad_con->implementation
()) 83 : 0;
84
85if (dad_eng)
86 dad_eng->announce_grob (info);
87 }
(gdb)
dad_con was introduced by the commit in question. It looks like
dad_con->implementation is of a wrong type. I hope it should be easy
to fix for somebody who knows C++.
--
Regards,
Pavel Roskin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 11 in lilypond: beamlet on wrong side of tuplet sixteenth
Updates:
Labels: -Patch-new Patch-needs_work
Comment #24 on issue 11 by pkx1...@gmail.com: beamlet on wrong side of
tuplet sixteenth
http://code.google.com/p/lilypond/issues/detail?id=11
Make passes but make check fails on
\sourcefilename
"/home/jlowe/lilypond-git/input/regression/beamlet-point-toward-beat.ly"
\sourcefileline 0
\version "2.15.17"
\header {
\texidoc = "
Beamlets should point in the direction of the beat to which they
belong.
"
}
\relative c' {
b16. b32 b32 b16.
b16.[ b32 b b b b16.]
}
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 11 in lilypond: beamlet on wrong side of tuplet sixteenth
Comment #23 on issue 11 by carl.d.s...@gmail.com: beamlet on wrong side of tuplet sixteenth http://code.google.com/p/lilypond/issues/detail?id=11 Sorry, I left out the Rietveld code link http://codereview.appspot.com/4941041/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 11 in lilypond: beamlet on wrong side of tuplet sixteenth
Updates: Labels: -Patch-needs_work Patch-new Comment #22 on issue 11 by carl.d.s...@gmail.com: beamlet on wrong side of tuplet sixteenth http://code.google.com/p/lilypond/issues/detail?id=11 New patch set uploaded Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2000 in lilypond: Patch: Fixes NoteColumn vs SpanBar collisions.
Updates: Labels: -Patch-new Patch-review Comment #15 on issue 2000 by pkx1...@gmail.com: Patch: Fixes NoteColumn vs SpanBar collisions. http://code.google.com/p/lilypond/issues/detail?id=2000 Passes make but lots of reg test diffs as usual http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-7-Nov-2011-td4962666.html James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2014 in lilypond: Patch: Improve HTML output of regression tests
Updates: Labels: -Patch-new Patch-review Comment #4 on issue 2014 by pkx1...@gmail.com: Patch: Improve HTML output of regression tests http://code.google.com/p/lilypond/issues/detail?id=2014 passes make and no reg test diffs james ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2020 in lilypond: Patch: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline'
Updates: Status: Started Owner: adam.spi...@gmail.com Labels: -Patch-new Patch-review Comment #2 on issue 2020 by pkx1...@gmail.com: Patch: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' http://code.google.com/p/lilypond/issues/detail?id=2020 Passes make and no reg test diffs. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Updates: Labels: -Patch-countdown Patch-review Comment #20 on issue 1572 by pkx1...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 Passes make and two reg test diffs attached James Attachments: Screenshot-1.png 53.2 KB Screenshot.png 142 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: -Patch-new Patch-review Comment #32 on issue 1503 by pkx1...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Passes make and two reg test diffs attached James Attachments: Screenshot.png 142 KB Screenshot-1.png 53.2 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2000 in lilypond: Patch: Fixes NoteColumn vs SpanBar collisions.
Comment #14 on issue 2000 by mts...@gmail.com: Patch: Fixes NoteColumn vs SpanBar collisions. http://code.google.com/p/lilypond/issues/detail?id=2000#c14 Fixes NoteColumn vs SpanBar collisions. http://codereview.appspot.com/5323062 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2014 in lilypond: Patch: Improve HTML output of regression tests
Updates: Labels: Patch-new Comment #3 on issue 2014 by adam.spi...@gmail.com: Patch: Improve HTML output of regression tests http://code.google.com/p/lilypond/issues/detail?id=2014#c3 Improve HTML output of regression tests - Use Javascript to enable filtering of table rows by type - Make sure git file compare cell contents are HTML-escaped - Fix some HTML validation issues http://codereview.appspot.com/5342042 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2020 in lilypond: Patch: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline'
Updates: Labels: Patch-new Comment #1 on issue 2020 by adam.spi...@gmail.com: Patch: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' http://code.google.com/p/lilypond/issues/detail?id=2020#c1 avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' http://codereview.appspot.com/5361042 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Comment #19 on issue 1572 by adam.spi...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 Now resubmitted as http://codereview.appspot.com/5343050/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Comment #31 on issue 1503 by adam.spi...@gmail.com: Feature request:
simplify jazz chord display
http://code.google.com/p/lilypond/issues/detail?id=1503#c31
Issues 1503 and 1572 - Add an entry to changes.tely for improved jazz chord
support.
Issue 1503 - add support for "altered" jazz chord (super-Locrian)
Fix indentation in chord-ignatzek-names.scm
Doc: fix spurious pluralisation typo in Chord name chart appendix
Issue 1503 - add additionalPitchPrefix to allow choice of prefix for
additional pitches in chords.
This was previously "add", e.g. "Cmaj7 add6add9",
but this results in too much clutter and
is rarely used.
Issue 1503 - Allow choice of minor chord modifier.
For example, often it is preferred to use a hyphen
instead of "m". This can now be achieved via:
\set minorChordModifier = \markup { "-" }
Add slashChordSeparator
Issue 1572 and issue 1503 - Allow choice of chord modifier separator
independently of chord inversion separator, since conventionally the
latter is always a slash (hence the term "slash chords"), whereas the
former seldom involves slashes.
Add some missing chords to the ignatzek regression test
Issue 1503 - Recognise Lydian chords
Issue 1503 - Enlarge half-diminished slashed circle symbol
Replace tabs with spaces in scm/chord-ignatzek-names.scm
http://codereview.appspot.com/5343050
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #50 on issue 1852 by philehol...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 Issue 2028 raised. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2028 in lilypond: Make doc always recreates HTML files
Status: Accepted Owner: Labels: Type-Build New issue 2028 by philehol...@gmail.com: Make doc always recreates HTML files http://code.google.com/p/lilypond/issues/detail?id=2028 As the title says. Run make, make doc and then make doc again. The HTML files all have fresh timestamps. It would presumably speed up make doc to avoid building these when they don't require a rebuild. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Updates: Status: Verified Comment #49 on issue 1852 by philehol...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 I bought a machine to make it possible to make doc quicker - it can build docs from scratch in about 12 minutes. I'll verify this one and raise a new issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #48 on issue 1852 by julien.r...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 The output would be interesting to be sure, and I think it should get a separate issue number. And thanks again, a make doc on your machine seems to happen about six times faster than on mine, but it's still always a real drag to test these patches to the doc build. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #47 on issue 1852 by philehol...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 If you want the output of what I now call the null make doc, please let me know. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #46 on issue 1852 by philehol...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 Just done that and get the same result: all HTML files are remade, PDFs are untouched. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #45 on issue 1852 by julien.r...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 I think you would do it this way, on the up-to-date machine: git checkout d30221fa73101baffcb05ec49ec04d366a471824~1 to return to a tree that is one commit before this patch, then test the build (starting from a new build dir: make, make doc, and make doc again) and report back. When you're done, git checkout master to return to an up-to-date tree. Thanks. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #44 on issue 1852 by philehol...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 I could try this in 2 ways: I'd prefer the first if you could guide me. My fast build machine is now up-to-date as of yesterday. I assume I can roll it back to before your changes, but am not familiar enough with git to know how. If you could talk me through it, I can do it. Otherwise I have a not-recently-updated VM on my windows box, but I'm not sure whether it would include the patch you're talking about or not. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2005 in lilypond: scripts move unnecessarily away from accidentals
Updates: Status: Fixed Comment #7 on issue 2005 by mts...@gmail.com: scripts move unnecessarily away from accidentals http://code.google.com/p/lilypond/issues/detail?id=2005 Pushed to dev/staging as 7358116188985b145e760497c847908ad98706c0. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2027 in lilypond: make website doesn't have dependencies
Comment #1 on issue 2027 by julien.r...@gmail.com: make website doesn't have dependencies http://code.google.com/p/lilypond/issues/detail?id=2027 I think it's a matter of copying the definitions for the macros "DO_TEXI_DEP", "scan-texi", and "find-texi" (with some adaptations, e.g. replace $(outdir) -> $(OUT); also, I think $(src-dir) is undefined in website.make) from stepmake/stepmake/texinfo-vars.make to make/website.make, and add a line "-include $(OUT)/*.dep" to the latter. Unfortunately I can't access my development computer right now so I can't test the suggested approach. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2000 in lilypond: Patch: Fixes NoteColumn vs SpanBar collisions.
Updates: Labels: Patch-new Comment #13 on issue 2000 by mts...@gmail.com: Patch: Fixes NoteColumn vs SpanBar collisions. http://code.google.com/p/lilypond/issues/detail?id=2000#c13 Fixes NoteColumn vs SpanBar collisions. http://codereview.appspot.com/5323062 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #43 on issue 1852 by julien.r...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 Phil, the rebuilding of the html pages with every `make doc' is a real problem, I also mention this problem in issue 1526. I think that I experienced html pages being rebuilt before submitting the patch for the current issue, but I can't rely on my memory very well and I don't have access to my development machine to test with an older git checkout. Could you please confirm or infirm that the problem was introduced by the patch from the current issue? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Comment #18 on issue 1572 by adam.spi...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 Based on discussion in http://codereview.appspot.com/5320074 I have been advised to resubmit the whole patch series as a new Rietveld issue, so please hold off on pushing this. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Comment #30 on issue 1503 by adam.spi...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Based on discussion in http://codereview.appspot.com/5320074 I have been advised to resubmit the whole patch series as a new Rietveld issue, so please hold off on pushing this. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #42 on issue 1852 by philehol...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 I was referring to running make doc. Then making no further changes and waiting 10 minutes, then running make doc again. On my system all the .html files have a new timestamp. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: Patch-new Comment #29 on issue 1503 by adam.spi...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503#c29 Issues 1503 and 1572 - Add an entry to changes.tely for improved jazz chord support. http://codereview.appspot.com/5361043 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1852 in lilypond: manuals needs more explicit dependencies
Comment #41 on issue 1852 by adam.spi...@gmail.com: manuals needs more explicit dependencies http://code.google.com/p/lilypond/issues/detail?id=1852 Phil - this sounds bad. I could try to verify if you explain what a 'null make doc' is, and how I should attempt to reproduce. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2027 in lilypond: make website doesn't have dependencies
Status: Accepted Owner: Labels: Type-Critical Regression New issue 2027 by gra...@percival-music.ca: make website doesn't have dependencies http://code.google.com/p/lilypond/issues/detail?id=2027 The old website.make just rebuilt everything all the time, which was a bit wasteful but worked. The new website.make doesn't have dependencies on the internal .itexi files, so whenever those files are updated in git, I need to manually log in to the server and delete the website build tree to force a rebuild. It would be nice if the new improved website.make could take care of this "removing the directory" part. Or do proper dependency tracking. I don't care which. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tracker 1686 - Process question - separate Tracker Issues or handlepatches as part of T1686?
On Sun, Nov 06, 2011 at 06:03:55PM -0700, Colin Campbell wrote: > On 11-11-06 05:30 PM, Graham Percival wrote: > >Right. Which is why I think we shouldn't even *try* to check if > >patches actually work or not. If there's a bug report, then sure, > >check if the bug is fixed. But if it's just a patch without an > >attached bug report, then just mark it verified and get on with > >other stuff. > > Maybe I'm not using terms as commonly understood here: to me, a bug > report has an issue number e.g., T1686, generated by the Google > Issue Tracker. ah, I see. I've tried to use the terminology: - google code issue number - rietveld number but it's kind-of a vague problematic thing. If somebody can suggest better terminology, I'm all for it. I certainly think we should avoid the term "google issue tracker" to refer to rietveld, since that invites confusion with code.google.com/p/lilypond/issues/ It's tricky. :( > A patch *usually* has an issue number assigned by the Rietveld > codereview tool, but not necessarily, as patches can be published as > attachments to postings on devel. > > In order to mark a patch "verified", it *must* be associated with a > Tracker issue, where the status is managed. > Patches without Tracker issues are essentially invisible to the > rank-and-file Bug Squad as well as to the rank-and-file patch-nanny. > Tracker issues may or may not have patches, but their status is > easily reviewed. Patches may or may not be linked to Tracker issues, > but they can only be seen when they are linked, unless one does > repeated searches on Rietveld by (known) developer. I'm agree that those patches should be considered to be invisible, and no bug squad members should even think about dealing with those. We're in agreement here. > With that in mind, though, your point about automating the check to > see if a patch has been pushed, as the sole criterion for > considering it verified, certainly has my vote, as it removes the > verify task from the Bug Squad list of duties. well, automating that task will probably take an hour, but it's not urgent. Unless you do it personally, I doubt it'll be done in 2011... so it's still on the list of duties. But ideally it shouldn't, and there's hope / a plan that it'll be removed in the future. - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
