ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

Hi,

On Fri, Nov 29, 2013 at 2:13 PM, Ricardo Salveti de Araujo
<ricardo.salveti@xxxxxxxxxxxxx> wrote:
> On Fri, Nov 29, 2013 at 10:55 AM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
>> On Fr, 2013-11-29 at 13:38 +0100, Alexander Sack wrote:
>>> On Fri, Nov 29, 2013 at 1:25 PM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
>>> > hi,
>>> > On Fr, 2013-11-29 at 13:01 +0100, Alexander Sack wrote:
>>> >> On Fri, Nov 29, 2013 at 12:41 PM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
>>> >> > hi,
>>> >> > On Fr, 2013-11-29 at 11:32 +0100, Alexander Sack wrote:
>>> >> >> Hi,
>>> >> >>
>>> >> >> it seems you put a few changes up for discussion in one shot.
>>> >> >>
>>> >> >> Let's keep those separate and look at them one by one:
>>> >> >>
>>> >> >> >From what I see you basically propose three main things:
>>> >> >>
>>> >> >>  1. lets increase velocity of image production so we get 2-3 images
>>> >> >> produced in devel-proposed per day
>>> >> >>  2. make cron the technology we use to schedule and kick those images
>>> >> >> 2-3 times a day
>>> >> >>  3. increase manual testing done before "releasing" images create a
>>> >> >> broader touch-release team that will include avengers and manual
>>> >> >> testers and community etc.
>>> >> >>
>>> >> >> Let me look at them one by one and then give a bullet summary of what
>>> >> >> I believe we should indeed tweak for now...
>>> >> >>
>>> >> >> On 1.
>>> >> >> ======
>>> >> >>
>>> >> >> I think 1. is and was the goal. So I think noone disagrees with the
>>> >> >> benefits of having 2-3 checkpoints a day and we should just do it.
>>> >> >> Note: it actually always was that way when I ran the landing team and
>>> >> >> during release time. I believe we still do it, but if we don't we
>>> >> >> should certainly ensure that we get back to do this.
>>> >> > on the majority of days in the past we only had one image build per day
>>> >> > simply because there were to many landings to wait for and in the end we
>>> >> > had huge change sets that burned a lot of manpower when searching where
>>> >> > a regression comes from.
>>> >> >
>>> >>
>>> >> Let's fix that process problem first.
>>> >>
>>> >> All we need to do is to be strict about following the time windows for
>>> >> cutting images regardless of whether the image has a chance to get
>>> >> promoted or not. We haven't spelled things out like this before, so I
>>> >> am pretty confident that this discussion helped getting us there.
>>> > 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.
>> I don't see how it makes any difference if that latest image was built
>> by cron or a human ... or do we have a special "human touch" in manually
>> built images that I don't know about ?
>> :)
>>
>> for the last two weeks I mostly behaved like cron wrt building images
>> (exactly in preparation for this request since so many people asked me
>> why we don't do cronned images, I'm pretty sad nobody of them speaks up
>> in this discussion) it doesn't seem to have interfered with anything.
>
> Exactly, not having it in cron here didn't help us much.
>
> I just don't get why we're fighting against automation, if we can all
> decide to build in a fixed schedule and work to improve our CI to get
> the best usage of that we can.

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?


> Ricardo Salveti de Araujo