You stated:
all sorts of tests that we can't do in
public, and make tweaks and changes that we can't do in public. This is
mainly due to hardware NDA's, and security stuff.
End excerpt.
1. Are these NDA enabled tweaks, changes, and tests that are in the
production releases of IBM RH EL ("binary" installable "executables"
only available under license for fee) fully and identically
(defect-for-defect, etc) reproduced currently in CentOS (soon to be EOL)
and thus in SL, etc., assuming that these are built from the IBM RH
released source code?
2. "Security" -- you are including in this term the "hardening" of EL
compared to, say, Fedora or "enthusiast" distributions. If the
"security" is done to any application that is derivative of a source
code file that is under an "open systems" EULA, my understanding is that
IBM RH would be required to release, not under NDA, the same security
modifications.
2.1 Presumably, the large staff of legal professionals (eg, JDs)
employed by IBM (and thus IBM RH) would do whatever is necessary through
torts, actions, etc., to prevent the release of (1) or (2) to non-IBM
entities if release is viewed to negatively impact the "financials" of
IBM (including market share, cash flow, etc.). Even if the "other side"
has deep enough pockets to counter the above, by the time interval that
the legal proceedings have concluded (unless these result in a permanent
enforceable consent decree against the company and any of its successors
-- tied to the intellectual property and the derivatives/successors
thereof, not the current owner thereof), the modifications effectively
are syntactically "obsolete".
Yasha Karant
On 5/5/21 8:09 AM, Troy Dawson wrote:
>
> On Tue, May 4, 2021 at 10:01 AM Yasha Karant <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> If I correctly have read the RH EL9 CentOS announcement below, EL 9
> will be in production before the end of this year, leapfrogging EL 8 as
> it were.
>
>
> I just want to clean up one point, because it seems you mis-understood
> the announcement.
>
> RHEL9 will not be in "Production" before the end of the year. It will
> be in "Open Development". [1]
>
> Starting with RHEL8, RHEL now has 3 years between major releases. (8, 9,
> 10), and six months between minor releases (8.4, 9.1).
> RHEL9 will not go into "Production" until 3 years after RHEL8 was released.
>
> But development of a release takes several years.
> In previous releases, everything was done behind closed doors. For
> RHEL8 I wasn't allowed to even say I was working on RHEL8.
> For RHEL9, everything completely flipped open. The goal was, and is, to
> have everything as completely open as possible.
> If people want, I could go into each step, but let me make this brief
> and not do that.
> By the end of the year, you, or anyone, can watch the whole process[2].
> Not just the "here is this days/weeks/months release". But you will be
> able to watch, live, the RHEL developers git commits, merges, build,
> watch koji building the package, the package getting tagged, and so forth.
> That's why I'm calling it "Open Development", because anyone will be
> able to watch the development.
>
> So, what is the difference between that and a release?
> We (Red Hat) do not stand behind the packages until they are released in
> production. And only the packages released in production.
> There will be a time that we take one of the snapshots, bring it behind
> closed doors and subject it to all sorts of tests that we can't do in
> public, and make tweaks and changes that we can't do in public. This is
> mainly due to hardware NDA's, and security stuff. That internal testing
> takes months.
> After those tests and tweaking is done, and marketing says the time is
> right, we will release the production release of RHEL 9.0.
>
> I hope this clears things up.
>
> Troy Dawson
>
> [1] - "Open Development" is my term, not a Red Hat term. I find it more
> descriptive.
> [2] - There are three exceptions to the completely open process. 1 -
> embargoed CVE's, 2 - code partners will not let us show until released,
> 3 - some previously internal only package that got missed. Number 3 is
> small, and hopefully should go away.
|
