<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Jun 2019 at 14:10, Karanbir Singh <<a href="mailto:kbsingh@centos.org">kbsingh@centos.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 19/06/2019 18:47, Stephen John Smoogen wrote:<br>
> <br>
> <br>
> On Wed, 19 Jun 2019 at 12:32, Karanbir Singh <<a href="mailto:kbsingh@centos.org" target="_blank">kbsingh@centos.org</a><br>
> <mailto:<a href="mailto:kbsingh@centos.org" target="_blank">kbsingh@centos.org</a>>> wrote:<br>
> <br>
>     On 19/06/2019 17:18, Fabian Arrotin wrote:<br>
>     >><br>
>     >> We plan to compose all of those repositories, and deliver updates<br>
>     in the same stream.<br>
>     ><br>
>     > Just so that people realize : no *updates* repo anymore, so all<br>
>     combined<br>
>     > : if you install from network $today, what you'll install<br>
>     $tomorrow will<br>
>     > have all rolled-in directly<br>
>     ><br>
> <br>
>     that's not going to work - we need to retain the ability to deliver<br>
>     reproducible installs.<br>
> <br>
> <br>
> I think there is some confusion as what Brian is describing is what RHEL<br>
> has been doing since EL6.<br>
> <br>
> This isn't any different from what RHEL does now. You have a primary iso<br>
> image you instal from but if you point a kickstart to a<br>
> baseurl=<a href="https://cdn" rel="noreferrer" target="_blank">https://cdn</a>.<foo> you get whatever was in the compose of the day<br>
> (with all the previous packages there also but most installs will just<br>
> pull the latest). If you want a reproducible RHEL install you need to<br>
> only use the ISO or some similar frozen toolkit (Satellite, specific<br>
> local branches, etc) but otherwise you can get different installs each<br>
> day. Whether this is a good design or not is a different question... but<br>
> it is one which has been in place for nearly 10 years in the RHEL<br>
> upstream. [Currently the Fedora up-upstream does keep /updates/ but that<br>
> is done by other production tools.]<br>
<br>
unsure how/what you are talking about here - are you saying that we are<br>
going to adopt the RHEL delivery model ? if so, how are z stream going<br>
to work ? are we doing mappings for those as well now ?<br>
<br></blockquote><div><br></div><div>I am saying that with modules and unless you want to stand up a bunch of other things.. you are probably going to have to. However this isn't much different from how the current CentOS-7 is.. there are no Z streams for CentOS-7.. there is only the latest with dot releases being sort of rebased snapshots that are built off of upstream src.rpms.. So if people have been saying that there is no CentOS-7.7 there is just CentOS now.. then this would be taking that one step further. </div><div><br></div><div>By the way, I am only +0 on this at the moment. I can see why it looks attractive and makes certain work easier, but I am also aware it will makes deployment different/harder. But hey ~5 years ago we had a similar conversation on CentOS 7 minor version numbers with me arguing against going with 7.<YYYYMM> and wanting to keep 7.<minor>.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>