[Libreoffice-qa] Annouce: Bibisect for MACOSX
Robinson Tryon
bishop.robinson at gmail.com
Sun Dec 1 13:52:18 PST 2013
On Sun, Dec 1, 2013 at 1:04 AM, Norbert Thiebaud <nthiebaud at gmail.com> wrote:
> On Sat, Nov 30, 2013 at 5:52 PM, Robinson Tryon
> <bishop.robinson at gmail.com> wrote:
>>
>> I believe that the relationship would be 1 tb building into 1 bibisect
>> repo;
>
> Nope.
> I intend to have the TDF tb box build a daily 'for bibisect' build
> using a common config
> once a day but at different time of the day...
You say "the TDF tb box" -- do you mean multiple boxes?
> They will upload their install-dir (tar.gz) in a staging area in tdf infra
> and these will be stitched together later...
automatically, I hope? The QA Team has been expecting that daily
builds would be available promptly in bibisect repos.
> since they will not upload at the same speed and shit can happen... it
> is safer to stage first... so that the stitching can be tweaked.
> it is easier to script rebuilding a bibisect in part of in full using
> the tar.gz of the build rather than /insert/delete/move some commit
> after the fact
Interesting -- I'd assume that it would be roughly as easy to work
with the tarballs as with the commits in the repo. Storing all of
those builds individually might take a bit of space, but if we can
manage it, I don't see a reason not to hang on to the source tarballs.
> This will also allow.. in case a particular patch made the thing
> unbuildable for a while... to retrospectively re-build that section of
> the history using a 'patched' version at each step to avoid the the
> bug the prevented the build to start with...
When you say "re-build," if we're re-building from source, how would
the tarballs help us?
> I have done this on master covering the 4-2 dev period... where some
> patches broke the mac build for weeks at the time (on 10.6). the fixes
> where often trivial so a simple git check-out + fix of a single file
> was enough to still build... hence avoiding a 500+ commit range
> without builds...
I agree that we should avoid large commit ranges without builds.
My hope with bibisect is that we'll prevent any of the primary builds
from breaking "for weeks at a time." I think that there are enough
Win/Mac/Linux people on the QA Team willing to test against the daily
bibisect repos that we'll notice if the build breaks for even a couple
of days.
--R
More information about the Libreoffice-qa
mailing list