[CentOS] Fedora bugs and EOL [was Re: CentOS users: please try and provide feedback on Fedora] Boltron

Wed Aug 2 14:32:13 UTC 2017
Johnny Hughes <johnny at centos.org>

On 08/02/2017 07:27 AM, hw wrote:
> Jonathan Billings wrote:
>> On Jul 28, 2017, at 1:56 PM, hw <hw at gc-24.de> wrote:
>>> Are you sure that all the added complexity and implicitly giving up a
>>> stable platform by providing a mess of package versions is worth it? 
>>> How
>>> are the plans about dealing with bug reports, say, for squid 2.7, for
>>> those who need that version for a feature which hasnīt been included in
>>> current versions yet?  Just wait a bit until the distribution goes EOL?
>>> Is RH going to fix them once someone has bought their support?
>> I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
> I´m talking about Centos here and am referring to experiences with other
> distributions at the same time.
> Like Gentoo is great but horrible to keep up to date, and in doing so,
> you are expected to become a package manager yourself.  Things introduced
> into Fedora might make their way into RHEL/Centos, and introducing
> multiversion-packages into Fedora might lead to introducing them into
> Centos.
> Once they have been introduced, we need to become package managers much as
> with Gentoo in order to figure out which versions of which packages work
> together.  And that´s just the tip of the iceberg.
> What will happen when you report a bug in version N of package foo, perhaps
> a bug that was fixed in version N+2?  Are they going to fix it, or will
> they
> wait until the distribution goes EOL and/or tell you to use version N+2 ---
> which you can´t use because feature X is missing in that version, which is
> why you are using version N.
> Being able to use that very version N is the point of
> multiversion-packages.
> Not maintaining all provided versions of such packages accordingly would
> defeat the whole purpose.
> Perhaps issues like this haven´t been considered yet, that´s why I´m
> providing feedback as was asked for, after finding out that the form they
> have prepared to get feedback doesn´t allow to do so.  I´m aware that this
> is feedback they don´t want to hear and will either ignore or encounter
> with
> unkindness.
> Perhaps I´m entirely wrong and misunderstanding what they´re trying to do,
> yet so far nobody has said so.

In CentOS for the Base OS, our package management / versioning is quite
simple.  If it is in RHEL source code for RHEL, we build it as is ..
whatever the version.  If it works the same in CentOS as in RHEL (even
if that is broken), we release it.  Our goal is fully functional
compatibility with exactly the same versions as the RHEL source code and
the same behavior that RHEL exhibits.  So, we really don't make
versioning decisions or do techincal fixes, we change a bare minimum to
make sure people know they are using CentOS Linux (and to meet the Red
Hat branding requirements for RHEL).

Getting things fixed in CentOS Linux means informing the Red Hat team
that the source code contains bugs (either through Fedora or RHEL
sections of the Red Hat bugzilla) and getting them fixed upstream, when
the fix is released in RHEL, we will incorporate it in CentOS Linux.

For the Special Interest Groups (SIGs) things are much different.  They
are doing real development .. making versioning decisions, etc.  Some of
the things in SIGs have an upstream at Red Hat, some do not (for
example, there is a Xen4CentOS in the Virt SIG that maintains Xen on
CentOS Linux 6 and 7 .. that does not exist at all for RHEL).  We
maintain Xen dom0 kernel is unique in that SIG.

User feedback is important, but one has to make it to the proper place.
For SIGs, that is bugs.centos.org.  For base CentOS Linux .. unless we
introduced a bug in building (not usually the case), those are better
addressed with the upstream package maintainer (usually RHEL or Fedora

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20170802/af983f09/attachment-0004.sig>