that’s whacked

when a nightly that closes on a build date isn’t a build

Tuesday, Feb 28. 2006  –  Category: OpenSolaris

previously, every delivery we made was of a build snapshot. now that we’ve moved to weekly snapshot deliveries, i’ve moved to calling them nightly (as in synchronised with the 2006-02-28 nightly), rather than build-synchronised deliveries.

however, it’s important to still keep build-synchronised deliveries for projects like Xen & BrandZ which need build-synchronised sources to patch against.

there’s one problem though.

if you look at the ONNV build schedule, we see that 2006-02-27 is the close date for build 35. So the delivery that I will make later today (2006-02-28) means it should be build 35, right? Not exactly.

Danek, our illustrious and overworked ON gatekeeper, is responsible for delivering onnv_35 (the ON sources for Solaris Nevada build 35) to the WOS (i.e.: Wad Of Stuff… all the consolidations that go to make Solaris Nevada build 35). If it turns out that the 2006-02-27 nightly has problems, Danek may back out putbacks, or pull in put putbacks that happened post-build-close-date before delivering it to the WOS.

So what does that mean for the OpenSolaris community? Well, I can continue to deliver on time weekly deliveries… but this means that my nightly deliveries that sync on a build-close-date may not necessarily be exactly what comprises that build (in terms of Solaris Express). OR, I can delay deliveries in order to match up exactly with ON’s builds.

Personally, I much prefer to do the first option. This means that the source code you see is exactly what we’re working on internally – with no one-week delay. And whatever bug you may or may not see that Danek would have folded back in to the build snapshot, will probably (hopefully?) be resolved by the following week’s delivery.