{"action":"created","issue":{"url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts/issues/230","repository_url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts","labels_url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts/issues/230/labels{/name}","comments_url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts/issues/230/comments","events_url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts/issues/230/events","html_url":"https://github.com/CentOS/sig-atomic-buildscripts/issues/230","id":201749611,"number":230,"title":"downstream: enhance release process","user":{"login":"jasonbrooks","id":113114,"avatar_url":"https://avatars3.githubusercontent.com/u/113114?v=3","gravatar_id":"","url":"https://api.github.com/users/jasonbrooks","html_url":"https://github.com/jasonbrooks","followers_url":"https://api.github.com/users/jasonbrooks/followers","following_url":"https://api.github.com/users/jasonbrooks/following{/other_user}","gists_url":"https://api.github.com/users/jasonbrooks/gists{/gist_id}","starred_url":"https://api.github.com/users/jasonbrooks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jasonbrooks/subscriptions","organizations_url":"https://api.github.com/users/jasonbrooks/orgs","repos_url":"https://api.github.com/users/jasonbrooks/repos","events_url":"https://api.github.com/users/jasonbrooks/events{/privacy}","received_events_url":"https://api.github.com/users/jasonbrooks/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":16,"created_at":"2017-01-19T02:33:06Z","updated_at":"2017-05-12T23:07:31Z","closed_at":null,"body":"@cgwalters We've talked a bit about tagging downstream releases so that we can associate a particular state of the metadata in the repo with a given release. I was looking at how you do alpha releases, but that seems tied up in ci -- do you have thoughts about how we should do this for downstream releases?\r\n\r\nAlso, @kbsingh and I were talking in the meeting last week about setting up a process where, upon some release tagging event that happens in the repo, we'd have the nightly signed tree that KB is producing cut over to the official release location, allowing us to bring more automation to downstream releases. \r\n\r\nDoes that sound like something that'd work with the sort of release tagging I mentioned above?"},"comment":{"url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts/issues/comments/301205234","html_url":"https://github.com/CentOS/sig-atomic-buildscripts/issues/230#issuecomment-301205234","issue_url":"https://api.github.com/repos/CentOS/sig-atomic-buildscripts/issues/230","id":301205234,"user":{"login":"jasonbrooks","id":113114,"avatar_url":"https://avatars3.githubusercontent.com/u/113114?v=3","gravatar_id":"","url":"https://api.github.com/users/jasonbrooks","html_url":"https://github.com/jasonbrooks","followers_url":"https://api.github.com/users/jasonbrooks/followers","following_url":"https://api.github.com/users/jasonbrooks/following{/other_user}","gists_url":"https://api.github.com/users/jasonbrooks/gists{/gist_id}","starred_url":"https://api.github.com/users/jasonbrooks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jasonbrooks/subscriptions","organizations_url":"https://api.github.com/users/jasonbrooks/orgs","repos_url":"https://api.github.com/users/jasonbrooks/repos","events_url":"https://api.github.com/users/jasonbrooks/events{/privacy}","received_events_url":"https://api.github.com/users/jasonbrooks/received_events","type":"User","site_admin":false},"created_at":"2017-05-12T23:07:31Z","updated_at":"2017-05-12T23:07:31Z","body":"### proposed release changes\r\n\r\n* Align the centos atomic host release schedule with regular centos: new media, testing and announcements every month.\r\n* Assuming that the primary audience for cah is centos users, this gives users a general idea of what’s in a given monthly release, based on what’s in the equivalent non-atomic release.\r\n* rhelah ships roughly every six weeks, which means that there may be times when a centos atomic host could arrive almost a month after the rhelah release on which it’s based.\r\n* To solve this issue we add a second ref, that’s updated nightly (when there are updated packages). A user that wanted it could rebase to this ref and always be up to date w/ what’s in the repos.\r\n* Fedora does its two-week releases by copying a particular commit from its continuously updated ref to the two-week release ref, and then creating media based on that. We could do the same thing, but on a monthly schedule. https://pagure.io/releng/blob/master/f/scripts/push-two-week-atomic.py#_561\r\n\r\n### move to buildlogs\r\n\r\n* We serve our cah repo from http://mirror.centos.org/centos/7/atomic/x86_64/repo, which isn’t accessible via https. We want to switch to serving the repo from https://buildlogs.centos.org/centos/7/atomic/x86_64/repo, over https\r\n* We need to modify the centos-release-atomic package (https://git.centos.org/summary/rpms!centos-release-atomic) to include the new repo location, and we need to leave the old repo location in place for a while so that users pointed at the old location will receive the update pointing them to the new location.\r\n* Do we plan to serve the media from buildlogs, too? It seems to make sense to continue serving that from the same location as the rest of the media. "}}
{"actor":{"display_login":"jasonbrooks"}}