← Back to team overview

ubuntu-phone team mailing list archive

New rules in the landing process for the CI Train

 

Hi everyone!

After some discussion with both upstreams and the QA team, we came up
with a few modifications to the landing process and image promotion
criteria. The process will now become a little bit more strict, but we
tried finding a middle ground between ensuring high image quality and
landing convenience.

What changes will be happening?

First of all, whenever any test failure gets spotted by CI or the
Landing Team, a manual reproduction of the test steps will be performed
to check if the failure is a real regression or a test/infrastructure
regression. Depending on the result of that, a bug will be filled and
assigned either to QA or the upstream developers.

Now, if the test failure is a regression the standard thing happens - QA
decide if this blocks promotion or not.

In both cases a 'timer' will be started for the given issue. This timer
will be increased by one every day the issue remains unfixed. Once it
reaches a certain value, the issue becomes a promotion blocker by rule
and also blocking non-fix landings for the specific component.
The timer value for becoming a blocker will, for now, be set to 7 days.
This means upstream developers (or QA engineers) will have 7 days to fix
the issue before it becomes a bother to everyone. This value will be
tweaked after initial feedback of how well the 'system' works.

All necessary information will be made available on the daily landing
team messages. We can think about other ideas of visualization later on.

The result we want to achieve is putting a little bit pressure on
upstreams not to leave smaller issues 'lying around' on the image
because of their low priority. Leaving them unattended for a few days is
ok, but we had some that have been around since even months!

Let's try it out! See you next week!

Best regards,

-- 
Łukasz 'sil2100' Zemczak
 lukasz.zemczak@xxxxxxxxxxxxx
 www.canonical.com