Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
jkeating at j2solutions.net
Tue Sep 20 21:16:32 UTC 2011
On Sep 20, 2011, at 1:35 PM, Ralf Corsepius wrote:
> On 09/20/2011 05:30 PM, Doug Ledford wrote:
>> ----- Original Message -----
>>> I'd like to see a rationale for jamming a soname-changing update into
>>> the OS so close to a release. In the absence of a very good
>>> that's not good engineering practice, and it's not consistent with
>>> feature process.
>>> Perhaps you're not clear on what the word "freeze" means.
>> One rationale is that if we don't get it *before* the release when everyone is actively testing, then it ends up going in post release,
> Agreed, but what currently is happening, is packagers not being able to
> submit package chains _in time_ because of the delays.
> Reality is, when the root of a dependency chain changes incompatibly,
> there are situations, it takes weeks until the whole chain has been
> rebuilt. And when a freeze "closes down" update submissions, the repos
> end up in inconsistent and broken state.
>> likely with far less testing, and risks destabilizing the already released product.
> The way things currently are, these packages will land as part of "day
> one" mass updates.
A few releases ago, I believe a decision was made, or at least proposed, that broken dep resolution rebuilds should be automatically considered "Nice to Have", that is they are allowed to break the freeze, but the release would not wait for them. Maybe the missing part here is getting visibility on these broken deps into the blocker meetings so that QA/releng can do the necessary work to let those updates through.
More information about the devel