On Sat, Jan 23, 2016 at 07:57:29PM +0000, Guenter Milde wrote: > On 2016-01-21, Scott Kostyshak wrote: > > On Wed, Jan 20, 2016 at 10:18:14PM +0100, Georg Baum wrote: > >> Scott Kostyshak wrote: > >> > On Mon, Jan 18, 2016 at 03:59:16PM +0000, Guenter Milde wrote: > > > ... > > >> >> Alternatively, we could have an "untested" branch for commits that > >> >> should > >> >> go in after a test run... > >> > > >> > I would like this. But I'm not sure all LyX developers feel comfortable > >> > with git branches or with learning about git branches. > > >> IMHO developer objections to git branches are the smallest part of the > >> problem. Similar proposals have been made in the past, and nice workflows > >> have been proposed which make use of branches, but in the end a human or a > >> script needs to decide which parts of the untested branch get merged into > >> master, and this is the point where it fails. We neither have the > >> resources > >> for setting up an automatism (would be a lot of work), nor for manual > >> merging. > > The idea would be that instead of posting/mailing the patches, I would > commit them to the "untested" branch for some kind soul to run the tests. > If things are OK, I can merge to master and commit. > Would this make sense?
Yes I would be happy with this workflow. Fetching updates to a branch is more convenient than applying patches from email. We would also not have to worry about rebasing issues (well, when merging we would but at least that step can delayed). > >> >> Could you life with the the current description of "expectations of LyX > >> >> developers" (sec 3.3.1.1 in Develomplent.lyx): > >> > > >> > I can live with the below for most cases. For trivial changes, no need > >> > to run the tests. For non-trivial but small or medium changes, then the > >> > below is fine. However, for significant changes where one thinks there > >> > is a good chance that many (non-suspicious) tests will be broken, then I > >> > think the committer should be required to either run the tests or to > >> > post and wait until someone else runs the tests. I only expect this to > >> > happen for a few commits every release cycle. For example, changing from > >> > babel to polyglossia. Looking backward, it was expected that many tests > >> > could break. Another example is the reporting missing characters commit. > >> > I don't think there are many other commits that fall in this category of > >> > "I think there is a large probability that many tests will fail". > > The problem with this kind of patches is, that the hundreds of failures > were actually all "false positives" - problems with the tests or > follow-up LyX-bugs, not problems with the patch. I agree that there > should be coordination with the test suite maintainers but no requirement > to ensure a failure-free test run after patches where there is a > consensus that they do "the right thing". The developer fixing important > shortcomings usually does not have the time and expertise to solve these > test failures anyway. I see. > * There are "obscure" formats that are almost never really used (Lua/XeTeX > with 8-bit fonts, say). Another problem is that we don't know what is actually used by users. We cannot assume that they're doing sensible things, especially since LyX's interface sometimes encourages them to do the wrong them. > * There are tests that replicate most parts: .lyx->.tex->.dvi for > "dvi", "ps", "pdf", "pdf3" (usually it should suffice to test "dvi"). > > * Some changes only regard 8-bit TeX, others only Xe/LuaTeX. > > * It may suffice to test a simple document (splash.lyx or Intro.lyx) with > every language, or > > * if may be OK to test with just English, > > * ... > > I started with some examples in Development.lyx and consider to extend this. Scott
signature.asc
Description: PGP signature
