On 10/16/23 00:20, Peter Boy wrote:
Sorry for top posting. But my question doesn’t fit to a specific post. And I don’t like to contribute to getting off-topic. But ...
I followed the thread and various similar discussions closely. My question is: Who is really suffering from the famous „June decision“ of Red Hat? I don’t get it.
No one has denied that every fix or improvement of a software or a configuration finds its way into CentOS (stream) and its source repository (and hopefully into Fedora, too - much more important here). So as a member of the OSS community, I can take full advantage of any enhancement to OSS software developed by Red Hat and have access to the source code.
As a Red Hat customer, I obviously have access to the source code for the specific RHEL x.y.z version I am using, either - just in case I’m interested instead of the phone number in my support contract.
And as a student, programmer or even curious citizen who would like to know and learn how everything works, with a developer license I can look at everything and study and learn.
So, who _exactly_ is suffering?
I don’t get it and would really like to know. I put a considerable amount of time into Fedora. Maybe, I’m suffering without knowing? :-)
Previously it was possible to get the exact source code for the latest
version of any package of any major release of RHEL very easily. These
source RPMs could then be rebuilt into binary-compatible RPMs that
worked just like the ones in RHEL. And this was the case for nearly
every single SRPM in RHEL (maybe every single one? Not sure, there might
have been like 10 or so SRPMs that weren't public and contained Red
Hat-built binaries, but even those may have been publicly available
without a subscription and just also contained pre-built binaries).
As a result, there were (and still are) at least three projects that
simply took virtually every single SRPM in RHEL and rebuilt it, then
redistributed the binaries as a distro. These "RHEL rebuilds" are
essentially RHEL without the cost and without the support (or that are
supported by an entity other than Red Hat). Obviously these compete
directly with RHEL since they serve exactly the same purpose and are
cheaper.
These rebuilds were considered by RHEL to not be adding value to the
RHEL ecosystem (as I understand it). They weren't contributing anything
back into RHEL, they were just taking RHEL and making it free. Red Hat
finally decided that they didn't want to continue providing everything
their competitors needed to compete effectively with them, and now the
SRPMs for RHEL are "locked" behind an RHEL subscription. Additionally,
the ToS for an RHEL subscription no longer allows you to *download* the
SRPMs from Red Hat for the purposes of making an RHEL rebuild.
Note that the use of the SRPMs themselves is in no way restricted. You
are free to take the code in them, modify it however you want,
distribute it to whomever you want verbatim or in modified form, etc.
The code hasn't been encumbered, your use of Red Hat's server resources
is what now had limits on it. You can't use up Red Hat's bandwidth and
server power to download all their source code so you can rebuild the
whole entire repository yourself. This is similar to the Anaconda
Repository, where you can do whatever you want with the code in the
repo, but cloning the repo isn't allowed because of the ToS for the
*repo* (not the code).
I obviously have my own personal opinions on the situation, but I won't
be sharing much more of them here since I think that could re-spark an
argument. Suffice to say, I contribute to Fedora and intend on
continuing to do so.
I apologize in advance if anything I've said here isn't entirely
accurate - I don't have the time to double-check myself on everything
here. If I have something wrong, I'd appreciate being corrected.
Am 03.10.2023 um 23:30 schrieb Simo Sorce <simo@xxxxxxxxxx>:
On Tue, 2023-10-03 at 23:13 +0200, Leon Fauster via devel wrote:
Am 03.10.23 um 21:29 schrieb Simo Sorce:
On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
Am 03.10.23 um 20:46 schrieb Sérgio Basto:
On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce <simo@xxxxxxxxxx>
wrote:
Additionally *all* of the code is fully available in git form on
gitlab
as part of CentOS Stream.
We all know or should know that this is false. It's easy enough to
disprove with a counterexample:
https://access.redhat.com/errata/RHSA-2023:1918
Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in
CentOS Stream. It isn't there, and never will be.
it is here :
https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9
Since June 21 the strategy changed. Such commits do not get pushed
anymore. But you are right, to prove it a different example is necessary ...
You are wrong and have been mislead.
Nothing has changed in how we develop and publish code in gitlab.
Nope, I do not argue about processes at all. Its about resulting code
fragments. Speak, having in gitlab version 8 of a package and in the
current/latest RHEL release (9.2) version 7 with backports of 8 doesn't
mean that the code is in gitlab. The code differs and its not
accessible. Thats all about.
The code is still in gitlab, in most cases in directly accessible in
individual commits. In some cases, like the one Michael mentioned,
where a rebase landed early in the CentOS branch the code may land
together with other changes, but it is not like it is not there.
There are is a no regression policy in RHEL, so if CentOS is ahead it
means it already has all of the code in question.
And if there is an actual reason to need to know what exact change
landed in RHEL there are several avenues to find out (just grab a
developer subscription for example).
I just find that this is generally just a mental exercise, but not
something people do or need to do on a regular basis, and does not
prevent any use, study, sharing or enjoyment of the code.
Claiming the code is inaccessible sounds odd to me.
But perhaps I am just old and remember when all you got from upstream
was a tarball and you had to figure out what actual changes went in
manually with diff ... no commits or commit messages and often not even
a reasonable changelog ...
Simo.
--
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy@xxxxxxxxxxxxxxxxx
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
