Re: Don't update to current cooker

On 01/24/2012 06:49 PM, Jeffrey Johnson wrote:
> Well lets attempt "fully agree".
>
> The process workflow for cooker is essentially this:
>
>      SRPMS ->  BUILDSYSTEM ->  MIRRORS ->  USERS
>                      A                                B                     C
>
> I have make the transitions with {A,B,C} because that is the logical
> place to add better automation to achieve higher quality.
>
> Your "smarter build system" is at point B and "smarter" implies
> implementations to achieve higher quality.
>
> My original proposal was at point C, and slowing down the
> process flow implicitly assuming that manual/automated
> tools could be applied yo improve quality. Doing
> daily (rather than weekly/monthly) releases to USERS
> leads to quite predictable breakage, and there aren't enough
> hours in a day to attempt better QA at point C.
>
> I will point out that Per Oyvind's rpmlint work to improve
> the input SRPM recipes is at point A, which both better
> (because its earlier) and harder (because fixes at point
> A aren't so easily automated and require detection
> at B by rpmlint in order to achieve better recipes at A
> through manual editing).
>
> Can we fully agree on the above?
Yes.

>>
>> Breaks in cooker happen quite often, they are just not as big as the ones caused by Perl update. Some big updates can require more manual work and for them a special process can make sense, indeed. But I believe that such updates are not numerous/frequent.
>>
> I will never question your "belief" other than to point out that reality is
> sometimes different.
>
Surely :) But we don't seem to have reliable statistics for 
well-reasoned discussion.

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