Re: Orphaning all my packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux