On Dec 28, 2020 4:41 PM, redbaronbrowser via CentOS-devel <centos-devel@centos.org> wrote:

The CentOS governance had a stated obligation to be public, open and inclusive. ...

I further submit that the following governance board member have not posted to any CentOS mailing list over the entire year of 2020. Under the concept of meritocracy, they do not have merit to be on the board as they aren't active members of the CentOS community.

These MIA governance board members are:
Brian Exelbierd
Mike McLean
Carl Trieloff
Rich Bowen

How do we initiate a vote of no confidence in these non-community board members?

We users can't. The Board selects its own members; there has never been a "public" vote for the Board. In the context of CentOS as a project, what does "community" even mean?

I have always reckoned that the "community" in question consisted of contributors, not users. (I say that as a user, by the way.). This is not new; the people who have done the work over the years get to set governance, in my opinion.

Red Hat has stated that they will no longer fund a downstream rebuild (beyond CentOS 7 EOL in 2024 and CentOS 8 in 2021); it is apparent that as the owners of the trademarks of CentOS that they are similarly unwilling to allow these marks to be used for such a downstream rebuild beyond 7 and early 8.

At this point, no amount of argument, invective, complaint, or ad hominem attack will change this fact; according to posts by at least one Board member the Board approved those resolutions unanimously. (The minutes are available at https://blog.centos.org/2020/12/minutes-for-centos-board-of-directors-for-2020-11-11/ ; you're not likely to get a transcript, as the Board was in Executive session).

Note that CERN and Fermilab each have a seat on the Board.

The governance description on the actual CentOS.org site isn't exactly as you described. It's available for anyone to read, though, at https://www.centos.org/about/governance/

As to why we haven't had posts from certain people... the holidays are certainly part of the reason; the fact that these people actually don't owe the "community" any explanation is always another possibility. I've heard from enough people in "the know" by this point that I recognize the finality of this decision; now to make my own decisions.

If it's so easy to rebuild the RHEL 8 sources (I've seen people who should know better write something like, and I'm paraphrasing here, "now that the hard work is done with 8.0 it's simply rebuilding packages so it's not going to cost that much just to keep doing 8" which, to be brutally blunt, is just plain insulting the CentOS team who work hard each point release. There is no secret turnkey "RHEL rebuild engine" that's being hidden by the CentOS team; while gross rebuilding is easy; rebuilding correctly is hard, time-consuming, and thus costly. The process of rebuilding any given RPM out of git.centos.org is documented well enough to easily follow ( https://wiki.centos.org/Sources ); what's not documented is the process of dealing with the situations where the automatic build systems fail to produce a "compatible" result and require bespoke solutions.).

There is enough already documented that anyone with the skills and a lot of time on their hands can rebuild the RHEL sources; but it takes serious software building detective work to get near 100% binary compatibility. There is no easy button for build order (having comprehensive versions BuildRequires would help some). There have been references in-thread about build order bugs, and how it wouldn't be fixed until the next point release (it is instructive to figure out why).

Having said that, I wish the rebuild projects all the best. The most mature seems to be Springdale; time perhaps to check its binary-compatibility.

Will Stream cut it for me? One issue that keeps getting glossed over is that many drivers that are already in-kernel, not 3rd party, but disabled by Red Hat, still have users who need them. ELrepo and others have provided support at the "point release" milestones for these "unsupported" drivers; it really looks like Stream will break this hard.

For instance, I need megaraid_sas for my servers; that's not a 3rd party binary driver, but is already in-kernel; it is intentionally not built by Red Hat. ELrepo rebuilds this AND most importantly provides a working driver disk for installs; I just don't see Red Hat providing these drivers, even in a SIG, for hardware they have already decided is "unsupported "; but I always reserve the right to be wrong.