|
From: | James Lowe |
Subject: | Re: makelsr |
Date: | Fri, 28 Dec 2018 18:15:43 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
Thomas et al. On 28/12/2018 14:13, David Kastrup wrote:
Thomas Morley <address@hidden> 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 about2.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
[Prev in Thread] | Current Thread | [Next in Thread] |