ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

On Sat, Nov 30, 2013 at 12:31 AM, Steve Langasek
<steve.langasek@xxxxxxxxxx> wrote:
> On Fri, Nov 29, 2013 at 03:43:25PM +0100, Alexander Sack wrote:
>> it's not about automation or not and as I said before, I am surely not
>> fighting automation. I am simply against going back from a
>> potentially-smart, trigger based approach for one of our CI steps
>> (image production) to a cronjob based approach that is completely
>> arbitrary/decoupled from the rest of our engineering/landing process.
>
>> > And the archive is always open, besides the landing team syncing the
>> > landings first in a ppa and then in proposed, so we should always have
>> > an automated job that creates such snapshots.
>
>> The fact that the archive uploads are in a separate process makes
>> things hairy, yes. However, that doesn't means that we should add
>> another decoupled process (cronjob based image production) and hope
>> that things will be better....
>
>> > We should all work against the schedule, not against the will of the
>> > landing team to trigger a new image (as that's not really a CI), and
>> > please, we're engineers :-)
>
>> Note that the current proposal is to have a schedule. Not a point
>> schedule through a cronjob, but a smart, time window schedule.
>
>> How is such approach still an issue for you?
>
> My concern with something described as a "smart, time window schedule" is
> that it does not sound to me like a schedule that developers can rely on.

In the _cronjob world_ as a developer you either upload with a pretty
big buffer or you don't really care whether your change makes it into
the next image. In the _smart trigger world_ you can still do the
same, PLUS you can also chat with the landing team and be sure that
your change will not be accidentally missed.

So for example, assuming we announce that our midday image will get
produced earliest at 1300 UTC and latest at 1500 UTC, you can either
self-service yourself shooting for 1300 UTC (with the appropriate
buffer), or you talk to the landing team and get a priority treatment
:).

> Being trigger-based is nice in theory, but if we routinely wind up
> struggling for 3-4 hours to land particular components, and as a result miss
> the window for the build and wind up running up against build+1, then such a

The smart trigger can help flattening the 1h uncertainty you
implicitly mention by saying "3-4h". Of course, it can't help the fact
that landing anything will take at least 3 hours :).

> "smart" trigger isn't actually helping us, as compared to having a regular
> build every 8 hours of whatever's most current in the archive.
>
> Even if we have reason to believe a particular image won't be promotable,
> having these images regularly produced - and at greater frequency - is still
> useful for tracking down regressions.
>
> Maybe these issues are already taken into account and will be part of the
> announcement on Monday?

Yes, plan is to send out a schedule and that schedule doesn't include
the option to skip an entire image heartbeat.

>
> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                    http://www.debian.org/
> slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx