Issue #155: Decide on post-GA update cadence for various deliverables - atomic-wg

atomic-wg

#155 Decide on post-GA update cadence for various deliverables

Closed None Opened 9 years ago by maxamillion.

Currently there are plans to update release deliverables more formally post Fedora 24 GA. These aren't all going to happen immediately following the release but work will be done to enable them ASAP.

Some of these we've already decided on in the past but a couple still need decisions. The goal here is to simply determine what we would like to see as an ideal release cadence of updated deliverables. Technical implementation and details will be outside this scope.

https://fedoraproject.org/wiki/Fedora_Program_Management/Updating_deliverables/Fedora24#updating_deliverables

maxamillion commented 9 years ago

More information around the request for a 2-week atomic repo cadence as discussed during the meeting 2016-05-04 https://fedorahosted.org/rel-eng/ticket/6313

jasonbrooks commented 8 years ago

We discussed this in a fedora cloud mtg on Jul 20 (https://meetbot.fedoraproject.org/fedora-meeting-1/2016-07-20/fedora_cloud_wg.2016-07-20-17.00.log.html).

Currently, bodhi updates the testing and stable ostree repos when there are new testing or stable pkgs. There's a desire, expressed in the issue that Adam referenced above (https://fedorahosted.org/rel-eng/ticket/6313) for an ostree commit that coincides with the two week releases.

The requested changes, as summarized by Colin Walters, who filed the bug:

Colin's executive summary: Create a new additional ref:

fedora-atomic/f23/x86_64/batch/docker-host

Allow users to rebase to this who want it.

Change the two-week-atomic.py script to generate this (new rpm-ostree run, need to sed the json for the new ref)
then sed the kickstarts to pull from it (but still use a target ref of fedora-atomic/f23/x86_64/docker-host ?)
Decide on a version numbering scheme...e.g. also use a datestamp? So ostree.version=23.20160106, need to pass this to rpm-ostree

More detail, from another comment (https://fedorahosted.org/rel-eng/ticket/6313#comment:12) some months later:

The delivered/highlighted output is a combination ostree compose and image build(s) based on that compose, done every two weeks
Mirrors should contain the current image, the current compose and 3 prior composes (1 image and 4 ostree composes in total) - older composes may be pruned at will
Anything done more frequently should be for dev/test only, need not be mirrored and can be pruned at will

== Next Actions: ==

Do we have enough consensus to make the change? On Jul 20, jbrooks and dustymabe explicitly +1'd it. Colin requested it originally in https://fedorahosted.org/rel-eng/ticket/6313, and Adam seemed to agree as well.
Settle on the versioning scheme, does datestamp work?
Change the two week script (https://pagure.io/releng/blob/master/f/scripts/push-two-week-atomic.py)
Once the changes are in place and settled, consider process for dealing with critical security issues.