On Wed, 13 Jul 2016, Lou Berger wrote:
The quick test with the offending patch removed looked good. It just
found the already reported memory leak. I've started a more
comprehensive test on whole branch -- will take a~2.5 hours to run.
Cool.
I'll shuffle that from 'ff' to a 'nits' branch. And also have a look at
the 'make check' one Martin reported and see if about shuffling a fix in
after it - or squashing one in.
I gather people want any such rebased head to have a new name ('ffv2'?),
rather than re-using the old label for a new, non-fast-foward-mergable
head?
I'm also rerunning the step-wise basic (4min) regression through every
other commit to find the origin of the memory leak. -- just 109 (out
of 160) remaining!
Ouch.
For specific issues, git bisect can help. The '-x' argument to git
rebase is also good (I try do a -x 'make -j3' rebase to at least check
compile works - though there have been some patch-series submitted that
don't compile on a per-commit basis).
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Research is what I'm doing when I don't know what I'm doing.
-- Wernher von Braun
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
