On Thu, Jun 18, 2015 at 11:11:12PM -0400, Colin Walters wrote: > > Now updated based on some feedback and with a schematic of how I > > envision the build→test→release→present process working. If anything in > > that looks wrong, let's fix it sooner rather than later. > One thing that's absolutely essential here is to determine how the OSTree > commit process happens. Your diagram omits this AFAICS.
Thanks — yes, it does. My assumption was/is that it happens before the nightly timer. > Currently the tree compose happens as part of Bodhi for updates, > so whenever a package passes karma, and then goes through the whole > updates signing process etc, it gets committed to the tree > too - there's no Atomic-specific gating or checking. So, maybe it's better to actually trigger image build on tree compose (iff there's an actual change)? Although, actually, skipping builds if nothing changes for a day actually introduces complication down the line, because testing/release systems need to know that the build was skipped on purpose, not a failure. > But the high level question is - for delivery, does the tree stay > sync'd to the images, and have the same version, or not? > My initial take here is to sync the tree commit with the image for delivery, > but to have the tree operate asynchronously of image generation for > updates-testing. There needs to be a fast feedback cycle for > development inside the two weeks - this could be the updates-testing > ref that already exists. Is there a glossary of ostree terms somewhere? A ref is basically a branch, right? I was thinking that there would be two branches — main and testing. The testing branch would consist of "release + updates + updates-testing". (Possibly in the future this could be updates-bleeding, pulled directly from koji or some Copr with no bodhi step, but I don't want to overcomplicate initially.) The main branch would consist of "release + updates + selected packages from updates-testing". *thinking while typing* Hmmm, actually, it might make sense for _both_ of these branches to be "release plus human-selected updates from both updates and updates-testing", with those updates merged from the atomic testing branch to the atomic main branch when someone on the team judges they're ready. Mostly, I imagine, the updates that would be pulled in (first to testing, then to main) would be ones directly affecting the work — others could be left out, or there could be yet another branch which includes them all for people who want to opt in to them. This would also require someone to be responsible for selecting and including packages with security fixes. (Or possibly updates which are marked as security fixes in bodhi would go into at least the testing branch automatically?) Anyway, then: the nightly (and/or triggered) images would be in sync with the main branch. The released images would correspond to commits along that branch — possibly with specific names/tags (like 2015-w43 or 2015-r6 or whatever scheme we pick), if there's a way to go back and add those to the tree retrospectively — but there wouldn't be a released image for every commit. > (And for all of this two week discussion, we need to think about async > security errata and how that's versioned/tested/shipped) One possibility would be a manual trigger for the normally-twoweekly release scan. We should check with the security team, but I'm thinking that for a first pass, we could document the images as not being rebuilt async for security and advising doing an `atomic update`. -- Matthew Miller mat...@mattdm.org <http://mattdm.org/> Fedora Project Leader mat...@fedoraproject.org <http://fedoraproject.org/>
