Thomas et al.
On 28/12/2018 14:13, David Kastrup wrote:
Thomas Morley <[email protected]> writes:
Hi all,
I think we need some guidelines in the case a new lsr-snippet is used
for the docs.
See https://sourceforge.net/p/testlilyissues/issues/5251/
James askes not to run makelsr, because a plethora of changes will
clutter the patch-set.
OTOH, a patch can't stand alone and can't be applied for testings by
reviewers without makelsr. So I voted for doing makelsr.
The patch can be tested with makelsr as 'part' of the test process -
this is what I have done since I have been testing patches. After every
./configure, make, make test-baseline and patch apply, I then run a
makelsr.py before I run a new make, make check and a make doc.
There are two reasons really
1. The Rietveld has no noise in it for others to have to care about
2.it also doesn't cause a problem when I am testing against a current
master that has, by unfortunate coincidence, just had a patch merged
that also updated the snippet docs (because it needed a makelstr run
itself). This would, almost certainly, cause a conflict during testing
when I tried to merge the newer patch, with its own makelsr included,
because of all the 'snippet' doc files that would have just been updated
post older patch - if you see what I mean?
unless anyone else can come up with a more robust method, keeping
makelesr out of the review and patch to be tested is easier for all. A
simple - 'requires makelsr run' in the Tracker or Rietveld will alert
those that want to test the patch themselves that this needs to be done.
regards
James
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
