[Libreoffice-qa] Annouce: Bibisect for MACOSX

Robinson Tryon bishop.robinson at gmail.com
Sat Nov 30 15:52:51 PST 2013

On Sat, Nov 30, 2013 at 11:53 AM, Norbert Thiebaud <nthiebaud at gmail.com> wrote:
> On Sat, Nov 30, 2013 at 1:03 AM, Robinson Tryon
> <bishop.robinson at gmail.com> wrote:
>> Why not have the tb push builds directly into the bibisect repo?
>> https://wiki.documentfoundation.org/Development/tb#Variables
> because...
> 1/ keeping a local bibisect repo on each tb would be expensive in, if
> nothing else,  bandwidth

I don't know enough about the git sync algorithms to say much here --
I know that git does some de-duplication, but IIRC git doesn't always
minimize the amount of data transfered, especially if the repo has
been re-packed.

> 2/ multiple tb upload stuff.. synchronizing htem can be difficult,
> especially with wide variation in upload bandwidth

I believe that the relationship would be 1 tb building into 1 bibisect
repo; I'm not sure what sync/bandwidth problems we'd run into (aside
from what I've mentioned above). Are you suggesting that we might have
2+ tb's feeding into a single bibisect repo?

> 3/ the order of commit in the bibisect matter.

Right, but don't tb's usually build commits in order?

(assuming that we have 1 tb for 1 bibisect repo...)

> 4/ experience shows that somethings things break for some minor
> details.. being able to fix things an recover using staged build is
> useful

Being able to curate the particular builds that go into a bibisect
repo sounds great to me, as long as we have someone with the time to
do that :-)

> 5/ having some kind of control over the bibisect buidling as it build
> is good. it is easier to do when a centralized script do the job..
> then one can review the log and decide to re-do thing if need be,
> before the problem is buried too deep.

Again, hand-holding is nice, but I'm not expecting that we'll have the
engineering resources to do that with the GNU/Linux and Windows
bibisect repos.  My understanding is that we'll just add a new build
(or two) every day and hope that most of them aren't broken :-)

Speaking of which, once we do get daily builds feeding into the
bibisect repos, I'm going to try to get QA to test off of those repos
as much as possible. That should help us identify regressions much
more quickly and allow us to get regression bugs back to the Devs so
that they can be fixed before we push out a new release.


More information about the Libreoffice-qa mailing list