ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

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.

Cheers
Sergio