On Thursday, January 14, 2021 8:11 PM, Carl George <carl at redhat.com> wrote: > I have yet to see an actual problem presented other than "I don't > like the appearance of a downgrade". Technically, in the short term, that is true. For the long term there is bigger issues but I will get back to that later. > It's not ideal but it's also not causing an actual issue. Ok then. Well, that point has been made clear. > As long as RHEL maintainers add digits after the %{?dist} > macro in the release field, it will be possible to end up in > this situation. Wow. Ok, to be clear to you about reality: RHEL maintained SPEC file has a release of: 30%{?dist} CentOS maintained SPEC file has a release of: 30%{?dist}.0.1 Why are you finger pointing at the RHEL maintainers for "add digits after" when that just is not reality? Where in the RHEL maintained SPEC file are you seeing any digits added after the %{?dist} macro? > CentOS cannot solve this with the current implementation > of modularity in MBS. The right place for this feedback > is upstream MBS. Ok. More finger pointing. As far as I can tell, MBS is doing exactly what MBS is supposed to do. How would you like this "bug" to MBS to be worded exactly? Here is what I see having gone down: (1) Community member (who happens to also be a Red Hat employee) provides detail post asking to move just FOUR characters in the SPEC file and carefully explained the reason for the request (2) Johnny Hughes writes back with a quick dismissive response ignoring all that is being asked is to move four characters in the SPEC file (3) I try to restate the problem and solution (4) Red Hat respond with a dismissive explaination about MBS (5) Another person involved with Fedora recommends simply changing the epoch in the spec file (6) Original person confirmed being able to rebuild from RHEL and side-grade to Stream is a use case they may have in the future (7) And Red Hat doubles down on being dismissive, not seeing the problem and using finger pointing You don't see the problem or a reason to apply the simplistic solution because you have no motivation to work with the community to see it. You have nothing to lose by finger pointing and nothing to gain by helping apply the fix. Here is the actual problem: On November 11, governance board set a termination date for CentOS 8 in 415 days in favor of Stream. Karsten Wade indicated this is not about loosing something but rather gaining openness. Others have indicated on the mailing list that this is because Red Hat wants to hear from community. Today is 15% of the way towards the termination date of CentOS 8. The community has indicated something misleading being stated in one of the early steps that a Stream adopter would run into. The community has also suggested two easy fixes, move the four characters in the release string or add an epoch. The feedback and the fix has been provided. The response at 15% "progress" is to dismiss and to fail to "see." And this is a simplistic case. The feedback will continue to get more complex over time. For example, CD/CI testing will not be able to detect all regressions. There will be things like USB-HID that will at some point depend on the community for feedback. So, if there is a regression with USB-HID impacting an accessability device, say a non-standard replacement for a mouse, to what degree will Stream be closing the "openness gap" to work with the community on that? Will the community have access to individual Stream kernel patches to make it easier to track down where the regression is taking place? The answer so far has been no. The kernel will still be an obfuscated tar-ball. We have not been closing that part of the openness gap. If the community still tracks down the problem and provides a solution, how will we be able to get in included? Is it possible the response from Red Hat that they don't see the problem? Is it possible they will indicate someone that can not use a standard mouse should just stop "disliking" standard mice? The answer so far seem to be that is possible. Red Hat seems to be willing to be dismissive if the problem does not impact enough people even if a solution is already provided. We already saw how much progress can be made in 415 days when Red Hat says it is going to become more "open" with the community. We went through that in 2002-2004. Red Hat's attitude of being dismissive of the community continues for a while longer than just 415 days. Red Hat is self-imposing an aggressive schedule. There has not been 15% worth of progress made yet. On Jan 1, 2022, not only will we no longer be getting CentOS 8, we won't be getting the closing of the "openness gap" either. Once it become clear the CentOS community getting neither CentOS 8 or "openness," the ability to advocate on behalf of Stream use will be that much more impeded.