On Thu, Dec 12, 2013 at 5:33 PM, Pedro <[email protected]> wrote: > Hi Robinson > > I'm not sure I understand this bibi stuff but isn't it easier to have a user > friendly version that just runs the last release of each branch (actually > that is what I do with portable versions under Windows)?
What kind of search pattern do you use? > Then when the branch is located, run the final version for each release. > This would give you the subversion. do you mean the commit hash? > If the bug/regression is located between two subversions then run each > release (betas, RCs or dailies if available) > > The first two steps are quite easy and at the moment should take around > 2-3Gb each (6 versions x ~350Mb) The basic plan with bibisect is to do a binary search[1] on a set of builds listed in chronological[2] order. We can find the culprit commit or commit-range very quickly, which is why it is such an effective search technique. > > The last step could be left for the advanced QA people :) My suggestion regarding improvements to bibisect are based on my conversations w/Bjoern and Norbert, and are, essentially: 1) Use 2 levels of binary search trees to improve performance 2) Put a simple interface on it to (a) Make it easier to use the tool (b) Reduce user-error By the time we're done with the GUI, I hope that bibisecting a regression will be easier than triaging a bug. Cheers, --R [1] https://en.wikipedia.org/wiki/Binary_search_algorithm [2] It's actually more like "order in which they were committed," but "chronological" is close enough for our purposes. _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: [email protected] Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
