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

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?  

--
Jonathan Billings <billings at negate.org>

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.

On 08/02/2017 08:27 AM, hw wrote:
> Jonathan Billings wrote:
>>
>> 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.
>
I ran very early Gentoo versions (2005 to 2010) on my work laptop (a 
Compaq of all things) without any trouble.  I had very few issues with 
failed updates, since they are compiled on my system with my switches. 
The biggest PITA was to get the right switches added to get what you 
really wanted on the system.  I tinkered with KDE options for a couple 
of weeks (and the long compile times), but there weren't any issues 
usually.
> 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.
I don't this is as making us (the end user) package maintainers as much 
as package /controllers/.  I would fail to see much need to maintain 
multiple package versions on a system except for debugging/testing.  
However, as a former developer, I think this would make debugging much 
quicker and that's not a bad thing.  On the DevOps/Systems Engineering 
side (my focus over the last decade), this could possibly be a PITA if 
devs were allowed to run multiple package versions in production 
systems.  That's still not package maintainers, but a measure of control 
over them.
>
> 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.
They do that sort of thing all the time, it's called backporting. And 
lots of patches are backported.  Most of that is a function of how /far 
back/ to be backported, etc.  If they don't backport, you have a couple 
of options, backport it yourself, or find a comparable package with the 
features you need.
>
> 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.
That's insane.  Who in their right mind want to continue to maintain 
version 1.0 of a package when the current one is version 10.0 and there 
are 30 stable versions in between?  No one.  What are the odds the 
version 1.0 package would still be used in that situation? (even given 
short release times)
>
> 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.
>
I don't think you're wrong, and I don't think you're
misunderstanding
either.  It's kind of a bit of both, however contradictory that sounds.  
To me, Boltron seems to be a start on an idea whose time has come.  
Maybe it's too early for it, but I'm really looking to put it through 
it's paces to see how well it does work in real life situations.


-- 
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney at neonova.net
www.neonova.net

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
bugs).

-------------- 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-0001.sig>