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 _______________________________________________ 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
