On Sat, Nov 30, 2013 at 11:53 AM, Norbert Thiebaud <nthieb...@gmail.com> wrote: > On Sat, Nov 30, 2013 at 1:03 AM, Robinson Tryon > <bishop.robin...@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. Cheers, --R _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org 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/