David Ostrovsky-3 wrote > ... > I expect that master is always green. My definition of green is: > > $ make check > > with --enable-werror is passing on all three platforms: Linux|Mac|Win > 64.
Hello, Master seems to me the ref code for: - debugging,(to know if a bugtracker shows an existing bug in last version or if, in fact, it's already fixed) - retrieve bts (same reason than above) - for tools like coverity, cppcheck and others - feature branches since they fork the master branch and, at the end, merge with it. - small refactoring/cleaning/janitorial/ ... patches - translation - help part perhaps other parts I forget Now a TB can be red because of a new patch which includes a bug, in this case, the patch should be fixed or reverted within less than 1 or 2 days max. Also it can be red because of a patch which reveals a bug or multiple bugs, in this case, either bugs can be fixed quickly or it should be reverted within some days. After this period, if it's still not green, it should be reverted for some time until patches may help to solve the bugs to "revert the revert" and give a new try. Also, what's the point to add unit tests, to think about new test infrastructure, request people for bug hunting, etc. if we just let TBs being red? So long failing tests should be on local or on a feature branch to limit the impact In brief, any TBs should be most of time all green. Of course, just my humble (and perhaps naive) opinion :-) Julien -- View this message in context: http://nabble.documentfoundation.org/Changing-mindset-of-core-LO-developers-to-the-status-of-master-was-test-infrastructure-ideas-appreci-tp4151204p4151317.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
