Broken master and newcomers.
nthiebaud at gmail.com
Wed Apr 6 22:22:01 UTC 2016
On Wed, Apr 6, 2016 at 1:04 AM, jan iversen <jancasacondor at gmail.com> wrote:
> I experience quite frequently that new contributors follow the instructions, but end up with a master that will not compile,
these day that is unlucky:
here are the stats for the last 14 days:
from:Wed Mar 23 21:30:24 2016
master linux rel jobs: 296 ok: 282 ko: 11 fail ratio: 3.72 %
break: 9 broken duration: 2.12%
master linux dbg jobs: 242 ok: 226 ko: 15 fail ratio: 6.20 %
break: 12 broken duration: 2.98%
master mac rel jobs: 281 ok: 274 ko: 7 fail ratio: 2.49 %
break: 4 broken duration: 0.86%
master mac dbg jobs: 285 ok: 282 ko: 3 fail ratio: 1.05 %
break: 2 broken duration: 1.95%
master win rel jobs: 222 ok: 212 ko: 10 fail ratio: 4.50 %
break: 4 broken duration: 1.00%
master win dbg jobs: 229 ok: 215 ko: 14 fail ratio: 6.11 %
break: 7 broken duration: 2.64%
master win64 dbg jobs: 232 ok: 216 ko: 15 fail ratio: 6.47 %
break: 7 broken duration: 3.19%
broken duration is giving you the following info:
if you randomly pull master at any time in the period considered: what
was the odd that it was broken at that time
during the last 14 days your odd varied from 1 in a 115 for mac
releases build to 1 in 30 for windows64 dbg
let's look at windows dbg:
the last break right this minute on windows dbg was 1 day 9 hours ago
"Device or resource busy"
either a parallelism problem in our build system or a bug in Windows.
master was not really red because of that.
the previous break was
2 days 5 hours ago.. direct push by sberg
the one before was 2 hour earlier
that one seems attributable to Windows crappy FS.
the one before that was
5 days 13 hours ago, this one failed on win-dbg tb but passed Jenkins.
the one before that was 6 days 11 hours ago
that was due to 41bdaa37cc62f656cc164992c4c7d39bec7e57e2 a direct push by noel
the one before that was 7 days 16 hr ago
and was not due to the commit.. but some jenkins <-> windows interaction problem
Note that these kind of 'break' would not actually impact someone
iow it is red in ci but not really red
so of the win dbg break... 3 where due to windows glitches. 1 was
properly vetted by Jenkins but still failed in that tinderbox
2 could have been avoided by using gerrit.
but in the end that is 3 real break in 2 weeks for a real red duration
of 2 hours 38 minutes that is 1 chance in 127 to get a random red
so :"I experience quite frequently " seems to be a 'count the
his/ignore the misses' kind of thing.
IOW: my advice... let's keep nudging people to avail themselves of the
CI facility and avoid direct push...
that would have change the odd of a random red pull from 1 to 127 to 1
in 305 in this particular case.
but let's not forget that not that long ago it was easier to count how
often windows was buildable rather than hunt the commit where it was
I also have another data point: the bibisect build: these are less
sensitive since I purposefully build them without Werror and I
purposfully do not run the checks
(the goal being to have binaries.. not to validate the build quality)
here are the result: this are the commit in bibisect that cover more
than 1 source commit. the number at the end of each line is the number
of unbuildable commit that are folded in that one bibisect commit
that is 405 commit in 48 break.
that is out of 5405 bibisect commit, representing 5810 source commit
there was 405 commit that would not compile and link
the 3 worse streak representing 79, 37 and 29 commit respectively all
occurred very early in the epoch (more than 2 month ago)
Finally there is a fairly easy way around this problem:
when you think about pulling go there and check the state of master...
if you see some red scroll down find a green point and get the sha of that point
clone and checkout a branch at that sha...
More information about the LibreOffice