On Fri, Nov 29, 2013 at 4:39 PM, Robert Park <robert.p...@canonical.com>wrote:
> On Fri, Nov 29, 2013 at 4:38 AM, Alexander Sack <a...@canonical.com> > wrote: > > On Fri, Nov 29, 2013 at 1:25 PM, Oliver Grawert <o...@ubuntu.com> 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
-- 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
