Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ...

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.