On Saturday, December 26, 2020 4:48 PM, Mike McGrath <mmcgrath at redhat.com> wrote: > On Sat, Dec 26, 2020 at 4:12 PM Chris Mair <chris at 1006.org> wrote: > >> Before you say "Stream", the single most killer argument against Stream > >> is that you have broken any trust when you moved the EOL of CentOS Linux 8 >> from 2029 to 2021. > > I think we lost a lot of trust due to a pretty serious mix-up about the EOL date announcement, but I don't think it has erased all the good Red Hat has done and continues to do. Can you quantify that? Can you list out all the good Red Hat has done and what score should be assigned to each of those items. Then also list the evil Red Hat has done nad what score should be assigned. We will then have a value of how much evil Red Hat still feels it can justify in the future while still being able to claim that at least the good still has greater weight than the evil. I don't think your statement is as reassuring as what you intended it to be. >> Now Red Hat employees jump through hoops to tell us how great that'll be. What >> guerantees that in two year's time you're not going to kill Stream because "it didn't >> provide anything to RH"? > > Nothing, we and all companies kill products all the time. I don't recall this level of outrage over mugshot. We're taking a big risk with Stream and if it doesn't work out, we'll make changes there too as we should. It makes no sense to continue doing something that isn't working out. What existing popular community project did mugshot replace? Imagine a parallel universe in which Red Hat does the following: (1) Red Hat declares it's support for a display server called Wayland (2) Red Hat then declares all documentation claiming such support is now out of date but doesn't tell anyone (3) Red Hat then has a meeting behind close doors decides to drop all assistance to contribute to Wayland and will replace it with Mir (4) Red Hat then announces the replacement with several excuses why it is for the good of the community Eventually there would be a wikipedia article titled "Mir (software)" with a controversy section. This behavior with CentOS is Red Hat's version of Mir. I would be willing to discuss this further with you on Wave but the company was not commited to Wave and replaced it. So, I would be willing to discuss this further with you on Gtalk... but the company was not commited to Gtalk and replaced it. So, I would be willing to discuss this further with you on Hangouts... or do I mean RCS? Please remind me, who is the dominate provider of instant messager services at this point? >> Somebody already mentioned "fool me once..."... >> >> I'm still angry and I still cannot believe you appear to be oblivious to the huge >> blunder you made with this incredible EOL shortening. You've basically killed the >> CentOS brand in one single move. > > We're not oblivious to it. If this were any other organization or relationship, we'd help make amends by giving you your money back. That's just not an option here. And you can say we killed it all you want, what we've done is significantly change it. You may not recognize it anymore but there are many people on this list who we talked to before the announcement and that we've seen now who are actually interested in coming on this journey with us. Thats good. We already understand there is a nameless set of cardinals selected to be notified ahead of time before the CATHEDRAL announced it to the public. None of us are asking for our money back or our time back. What was requested was that Red Hat treat the *Community* ENTerprise OS as a BAZAAR instead of leveraging it's ownership of the trademarks to bully the community into a cathedral model. > I suspect the very trust that you all were putting in Red Hat to continue to produce CentOS Linux as though it were actually a 10-year enterprise-grade distribution for production was part of the problem here. To further demonstrate that problem, many of the replies I've seen look as though people did their risk assessments with "we're relying on Red Hat for our OS" instead of "We're relying on a community for our OS." I'd imagine some of you are having very awkward conversations with your management chain about this. No one using Fedora or WildFly thinks that way. I can't imagine why anyone would think the Community ENTERPRISE Operating System would be confused with a project striving for enterprise-grade. But thank you for your warning about WildFly. I will pass the warning not to expect WildFly to be enterprise grade to users of Keycloak. > We wanted CentOS to flourish in development environments, in upstream Open Source CI, and to help with things like OpenStack. I'm not sure if we accomplished any of that. For those that think perhaps that was the mistake all those years ago, I personally agree with you. The biggest problem with OpenStack/RDO is the upgrade path. OpenStack has 2 releases every year just like Fedora. But if I install Fedora 24 and then upgrade incrementally until I get to Fedora 33, most things still work as expected. If I install OpenStack Newton and then attempt to upgrade incrementally to Train, things go badly quickly. There is a lot of work to be done. I would like to see the issues with OpenStack resolved. I would like a community built around RDO. But how Red Hat is going about things now is not about mobilizing the community. This sudden 1 year remaing on CentOS 8 just frustration and demotivating. We may not be asking for our "money" or asking back our time back invested in CentOS. But we also aren't going to be quick to invest more time into a company that has commitments to us just go out of date. But taking a step back. Let's say Wade's blog post is completely honest and Red Hat wants to close the openness gap. Does that make any openness gaps in Stream considered a bug? Do I file a bug report against the Stream kernel SRPM? Would anyone take it seriously? Is this something Red Hat really wants to resolve? Or is openness whatever Red Hat defines it to be internally and all other defintions are out of date? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201227/06016fba/attachment-0005.html>