-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/11/15 00:30, Karanbir Singh wrote: > hi guys, > > RHEL 7.2 was released a few days back and we've been busy sorting > through the code and working on the downstream CentOS Linux release > ( its going to likely be released in November and will be called > 7.1511 ). > > I'd like to make that content available on ci.centos.org ahead of > public release. And there are a couple of ways to do this : > > 1) either we update the provisioning service, so all requests for > a centos linux 7 machine will give you a 7.1511 build ( its 7.1503 > at the moment ), with all the updates etc posted in sync that way. > This also means that mirror.centos.org inside the ci infra will > look DIFFERENT from mirror.centos.org the real users see, since it > will be setup to look like the next release. Not the solution I was thinking of, as that would imply we'll have an installable tree with 7.1511 content, and that's not the case. So my idea was more something like : - - provision using the http://mirror.centos.org/centos/7/ url - - add the 7.1511 pre-released and unsigned/untested content as another repo in the kickstart. That means that new nodes provisioned with 7 will have directly newer packages installed. and we also need to enforce that repo to be available for the CI tests (kickstart can drop an additional .repo pointing to that internal temporary repo) The issue is that because it's untested, the provisioning itself can fail (due to conflicting packages, or other issues), leading to CI tests not being able to be launched (in worst case) I'd also like to keep the internal mirror.centos.org exactly the same as what is released and available publicly, and keep the untested/unsigned packages in another repository, so that it would be clear to see the root cause if there is a packaging issue, etc (like gluster packages - part of - available now in the 7.1511 repo) > > 2) we make the content available in a new set of repos, called > CentOS.next or something; and the ci users are able to optionally > tweak their build scripts etc to include or not include these new > changes. > Yes, at least $projects actually using the CI env would be able to opt-in > 3) we dont make this content available before its publicly > released. > > of all those bits, I like (1) best; (2) only delays the content > from hitting the ci infra by a week or 10 days. We dont usually > take longer than that from when the builds are done to when the > distro update is released. (3) just means that if there are > changes, failures or breakages in the ci tested code, we only find > out at the same time as the users - which isnt nice. > > thoughts ? > - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlZUBZoACgkQnVkHo1a+xU5f6gCfWzF/PzqPChG7CN4vMqgWerq0 t1IAnAlHZw1lWdbSW4bct9MACe9jLqRM =UePr -----END PGP SIGNATURE-----