On Wednesday, December 23, 2020 10:00 AM, Johnny Hughes <johnny at centos.org> wrote: > On 12/23/20 1:14 AM, Gordon Messmer wrote: > > > On 12/22/20 10:36 PM, Nico Kadel-Garcia wrote: > > > > > It's why I say they're taags" and find the model > > > mentioned here that "it's all one branch" to not match reality > > > > For fun, I'll try again: > > RHEL point releases are branches. 7.6 is a branch. 7.7 is a branch. > > You can continue running 7.6 and receive security updates after 7.7 is > > released. Those updates may include packages built specifically for > > 7.6, and not just a selection of the packages for 7.7. They're > > maintained in parallel, at the same time. They're branches. > > CentOS point releases weren't individual branches. There was only one > > CentOS 7 branch. CentOS 7.6 was just a point in time along the lifetime > > of CentOS 7. 7.6 is not literally a tag, but it's the closest analogy. > > There was no continued support for CentOS 7.6 after CentOS 7.7 was > > released. If there's no parallel maintenance, there is only one branch. > > In an VCS, you can create a branch and continue work, and later create > > another branch off of that and continue work, but if you never add any > > work to an older branch after a new branch is created, then you're only > > using branches in a very superficial sense. There are technically > > branches, but there's no difference in that workflow between several > > branches and just one, because you have just one linear history > > containing every commit. This resembles CentOS updates. > > RHEL point releases get updates that aren't just updates for a later > > release. As an analogy, there are updates in the older branches that > > aren't in the new branches, unlike CentOS. > > CentOS has just one branch: > > > > - 7.5 > > \ > > * 7.6 > > \ > > * 7.7 > > > > > > RHEL has multiple branches that overlap in time: > > > > - ---- 7.5 > > \ > > * ---- 7.6 > > \ > > * ---- 7.7 > > > > This is 100% exactly accurate. AND, this is how it has been since the > beginning of CentOS Linux. > > Stream is really no different than this. Each major version is one tree > (IE CentOS Stream 8, CentOS Stream 9) > > There will be 5 years for each stream tree (after the release of the > RHEL 8.0 or RHEL 9.0 official release). This results in about 2 years > of overlap (or maybe slightly more) of 2 versions of Stream being active > at the same time so you can plan a migration from one to the other. Thank you for taking the time to share your perspective. However, if Stream is "really no different" then give is 5 years CentOS 8. Make the End of Life of CentOS 8 the same as CentOS 7. More importantly, before continuing to justify this change please work to give us the governance board we were promised. I don't understand why you of all people would allow your name to be used to give credability to an invalid governance board! Here is the announcement explained how the CentOS governance would work with CentOS joining forces with Red Hat: https://forums.centos.org/viewtopic.php?t=44407 Key items: (1) "The key operating points of the Board are going to be: Public, Open, and Inclusive." (2) "The Red Hat Enterprise Linux to CentOS firewall will also remain. Members and contributors to the CentOS efforts are still isolated from the RHEL Groups inside Red Hat, with the only interface being srpm / source path tracking, no sooner than is considered released. In summary: we retain an upstream." The governance board meeting that gutted CentOS' End of Life commitment date wasn't public, open and inclusive. There was no announcement for community particpation. There is no public transcript or chat log of the board meeting. There also was no firewall between CentOS and RHEL for the governance meeting. Brian "Bex" Exelbierd, a member of the RHEL team, was allowed to be part of the board in violation of stated CentOS governance policy. Kadsten Wade's blog post also explained that CentOS will *NOT* retain an upstream. It will *replace* being the upstream. Daniel Comnea (the person that started this thread) has asked we think before getting mad. I have read through his blog post. I have consider it all carefully including the his points about poor communication. But it is not just about poor communication, the community of CentOS was lied to about how governance would work after CentOS joined Red Hat. It isn't just that it was "possible" to communicate better. It was *required* that it be public, open and inclusive governance board. Not behind closed door with a member of the RHEL team. Comnea has pointed out that the hate toward Rich Bowen and Chris Wright is not fair. I agree with Comnea on this point. But Rich Bown and Chris Wright's documents talk as if this decision was made by a valid governance board. No one within Red Hat seems to be stopping to ask if Red Hat honored it's stated commitments on how governance would work. Was lying about how the governance process would work really expected to produce no backlash? I completely believe Comnea that Chris Wright is committed to Open Source. I'm not questioning that. I am also not claiming there is a conspiracy. I am saying Red Hat employees should feel an obligation to speak up about how this was an invalid governance board. Brian "Bex" Exelbierd and the rest of the RHEL team has no right to breach the firewall when making this decision. This is exactly what the community feared would happen. That is why I am still mad even after carefully reading Comnea's blog post. I do not like being lied to. It makes me mad.