Re: Don't update to current cooker

On 01/20/2012 01:21 AM, Jeffrey Johnson wrote:
> (aside)
> But how SHOULD large upgrades like perl/ruby be handled
> in "real time" when Cooker breaks not for any important
> reasons but because a large upgrade is in process?
>
> libpng 1.5 was another example: weeks to sort out a
> complex upgrade that (imho) need not have been
> distributed until complete?
>
> The cooker/rawhide model needs to change somehow.
>
> One approach would be to "bundle" large upgrades
> until ready. The problem there is that if two large
> upgrades are "isolated" then when each is released
> there will still be incompatibilities.
>
> Another approach would be to delay cooker updates
> to a weekly (instead of daily) time scale in order to
> permit time to do some simple QA (or perhaps even compose
> a minimal image like Franck is offering to do monthly).
> A longer time scale also allows users to judge when
> _NOT_ to upgrade if, say, the weekly release was Friday
> and the weekend were used to clean up issues. (Friday
> may or may not be the right day: but a weekly schedule
> might allow some time so that end-of-week was higher
> quality than beginning-of-week updates).
>
> There's *got* to be a better process flow here imho: needless
> (and endless) breakage is hard to keep up with.
Such problems can be partially avoided by using smarter build system 
which can automatically track at least dependency breakage, rebuild 
dependent packages, etc. For example, OBS (opensuse build system) has 
some possibilities of such kind. ABF is also supposed to provide some 
similar services.

-- 
Denis Silakov, ROSA Laboratory.
www.rosalab.ru