On Tue, Nov 10, 2015 at 03:30:24PM +0000, Guenter Milde wrote: > On 2015-11-10, Scott Kostyshak wrote: > > On Mon, Nov 09, 2015 at 11:19:16AM +0100, Vincent van Ravesteijn wrote: > >> And yes of course there is an implicit rule that when your commit breaks > >> something or has problems whatsoever you are expected to fix it within a > >> reasonable timeframe. > > This is, what I prefer. Could we make this an explicit rule: > > When your commit breaks something or has problems whatsoever you are > expected to fix it within a reasonable timeframe. > > If it is not possible to solve the problems, revert the commit or move it > to a "feature branch" (remember, branching is dead easy with Git). > > "Reasonable" depends on the problems involved and may range from 1 day to > some weeks.
This seems to be the most popular opinion. Günter, if you do not here any more comments, please feel free to put this in Development.lyx. > One problem with the current testing situation is, that many failing test > are due to fixes that correct behaviour that was wrong before (like > reporting missing characters in the output document as an error). > > Next, this led to discovery of the use of a wrong encoding with Xe/LuaTeX > and TeX fonts - solving this brought more problems to light. > > I believe such "indirect" problems must be solved "collectively" - after a > consensus whether to revert the "discovering" commit (and live with the old > hidden bugs), temporarily invert affected tests or do some hacks to get a > clean state, or have a concerted effort to solve the basic problems. Agreed. But I don't think this is a common situation. Scott
