<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Dec 2020 at 14:31, Mark Mielke <<a href="mailto:mark.mielke@gmail.com">mark.mielke@gmail.com</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 Mon, Dec 21, 2020 at 7:59 AM Stephen John Smoogen <<a href="mailto:smooge@gmail.com" target="_blank">smooge@gmail.com</a>> wrote:<br>
> On Sun, 20 Dec 2020 at 22:19, Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>> wrote:<br>
>> > > CentOS point releases do *not* match as closely as possible the<br>
>> > > corresponding RHEL point release?<br>
>> > No, no one is saying that.  Matthew said that you can stay at a minor<br>
>> > release of RHEL and still get security updates.  CentOS does not offer that.<br>
>> This is not correct. Please stop saying it. CentOS is bug-for-bug<br>
>> compatible with RHEL for *active* releases.<br>
> We came up with the phrase "bug-for-bug" compatible during EL5 as a GOAL to aim for. CentOS was NEVER bug-for-bug compatible. We aimed for it like a target to get to but we also had to release the software eventually and don't have the extensive testing mechanisms to prove 'bug-for-bug' compatibility. Sometimes CentOS shipped packages which did not have a particular bug because we could not exactly duplicate the build environment and other times we added new bugs because our build environment is not exactly the same.<br>
<br>
This is a good point of clarification. But, to be clear in both<br>
directions, please let us know if you agree that these points are<br>
correct:<br>
<br>
1. CentOS was intended to be "bug-for-bug" compatible with RHEL as a GOAL.<br>
2. This was especially difficult when Red Hat was not contributing to<br>
the project, as it involved a lot of guesswork and trial and error.<br>
3. This became easier when Red Hat began contributing, including<br>
staging the source for build, and providing the build engines.<br>
</blockquote><div><br></div><div>The methods for building the source to solution changed from dropping .src.rpm to git pushes in EL7 time frame. The build engine changed from running a highly modified version of plague? (reimzul) to koji. This did not make things easier or worse overall. Some things became easier and some things became harder. <br></div><div><br></div><div>What became easier was that Red Hat provided a lot of hardware and steady paychecks for 5 or 6 people who had been doing the builds in their spare time and out of pocket expenses.  <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">4. It's still not perfect, however, in almost every way there is<br>
currently a 1:1 relationship between the exact .spec file and patch<br>
set being used to build CentOS releases, in parallel (or a short time<br>
later) to RHEL minor release.<br></blockquote><div><br></div><div>A spec file is the tiniest part of making something match. Build order, hardware, etc have a larger effect.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
5. CentOS 8 Stream is a departure from the above. What is built in<br>
CentOS 8 Stream is *not* intended to be "bug-for-bug" compatible, but<br></blockquote><div><br></div><div>CentOS-8 has not been bug-for-bug compatible in the first place. We would still be working the initial release if we were trying that.  So please let us rephrase this</div><div><br></div><div>5. CentOS 8 Stream is not intended to have the goal of being "bug-for-bug" compatible. It is recognizing this is not possible and has not been possible since probably EL5. At any given time it is not necessarily aligned with RHEL X.Y or RHEL X.Y+1 but may be something in between or beyond depending on when the release cycle is happening.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">[That is the best over-simplification I can come up with this for.]<br></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>