Hi, On Fri, Nov 29, 2013 at 2:13 PM, Ricardo Salveti de Araujo <ricardo.salv...@canonical.com> wrote: > On Fri, Nov 29, 2013 at 10:55 AM, Oliver Grawert <o...@ubuntu.com> wrote: >> On Fr, 2013-11-29 at 13:38 +0100, Alexander Sack wrote: >>> On Fri, Nov 29, 2013 at 1:25 PM, Oliver Grawert <o...@ubuntu.com> 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 <o...@ubuntu.com> 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 -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
