On 14.10.2014 11:19, Stephan Bergmann wrote: > On 10/14/2014 10:51 AM, Bjoern Michaelsen wrote: >> Well, I see a good reason for that. I recently saw some bibisects being done >> with Mikloss dbgutils bibisect repo[1] and they seem to contain more "git >> bisect skip"s than everything else leading to less than optimal results. Now >> the fact that the branch apparently has so many asserts that fail regulary is >> unhealthy a topic of its own. But restricting our triaging here by failing >> too >> early is to be avoided IMHO -- and building bibisects with local patches is >> certainly a lot worse than yet-another-configure-switch.
this is a silly argument: asserts get added for a good reason, and if assert fails then that's a bug that needs to be fixed, and you can use a bibisect with debug enabled to track down when the bug was introduced. if you don't want asserts in your bibisect then please build a bibisect repo with debug disabled; that is certainly useful. also this problem is definitely not limited to asserts, i've seen it numerous times that i couldn't bibisect a particular bug in the repos you built because there happened to be another bug that made things crash at an earlier point. > If I understand you correctly, you mean using that bibisect repo like > > $ git bisect start ... > $ instdir/program/soffice > # do something specific in LO, leads to SIGABRT > $ git bisect skip > $ instdir/program/soffice > # do something specific in LO, leads to SIGABRT > $ git bisect skip > ... > > That sounds somewhat odd, given that at least "make check" apparently > does not generally trigger failing asserts, so I would not assume that > some random "do something specific in LO" would routinely do. Do you > have an example? it tends to happen in UI and framework code, which is hardly exercised by current tests... _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
