ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

On Fri, Nov 29, 2013 at 9:06 PM, Sergio Schvezov
<sergio.schvezov@xxxxxxxxxxxxx> wrote:
> On Fri, Nov 29, 2013 at 4:39 PM, Robert Park <robert.park@xxxxxxxxxxxxx>
> wrote:
>>
>> On Fri, Nov 29, 2013 at 4:38 AM, Alexander Sack <asac@xxxxxxxxxxxxx>
>> wrote:
>> > On Fri, Nov 29, 2013 at 1:25 PM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
>> >> why would it matter at all if an image gets promoted ... in my ideal
>> >> world we would have builds triggered every time a change set enters
>> >> from
>> >> proposed or at least every 2h ... only a minimal amount of these images
>> >> would be promoted at all, but we had a lot to pick the best one from ;)
>> >
>> > The reason for that is in a CI world we feed that image back so new
>> > merge proposals get tested on top of the most recent known good state.
>> > And this need to happen frequently, so folks don't test on outdated
>> > stuff etc.
>> >
>> > And yes, we currently don't have enough automation to be sure it's
>> > dogfood quality. But fixing that should be done through investing in
>> > more automation rather than changing the approach to put high latency
>> > manual and avengers activities into the middle of our rapid CI loop.
>>
>> This is a really impressive level of double-speak, and I think it
>> needs to be called out.
>>
>> Oliver is proposing a simple cron job that will increase the amount of
>> automation in the system, and reduce the amount of manual intervention
>> that is required for image builds. What you are proposing is a manual
>> system that requires a great degree of wasteful babysitting.
>>
>> It seems that we all agree that the ideal scenario is trigger-based
>> image builds (ie, build a new image any time anything lands in the
>> archive). But until that system is in place, a high-frequency cron job
>> is undeniably closer to the ideal than the current system of needless
>> busywork heaped upon already-busy people.
>
>
> I'm going to stick to the technical side here.
>
> There's one piece of the infra I don't really know yet (britney and/or
> moving from proposed to the archive); I'm going to assume that component is
> britney.
>
> When britney migrates the packages from proposed to the archive it could
> track if it's moving anything from the touch seed; it is, it could mark the
> image dirty (to some location the nusakan's cron can read from); then our
> high frequency cron on nusakan just checks the dirty flag; if it's dirty it
> builds and cleans it, if not it just exits.
>
> I really want us to have initially in_archive == in_image; but aspire to
> in_trunk == in_archive == in_image.

Wait. I think the term of high frequency cronjob is new in this discussion.

What are we talking about here? The proposed one build every 8h from
the initial proposal or rather something far more frequent (e.g. ever
few minutes)?