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

On 28/07/17 18:56, hw wrote:
> Matthew Miller wrote:
>> On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
>>> What?s the point of doing this with Fedora?  It?s not like bugs
>>> were fixed before Fedora is EOL and all reports are forgotten.
>>
>> Many bugs are fixed in Fedora. Many more bugs are fixed in the
>> upstreams. Please remember that Fedora is primarily an *integration*
>> project, and the best way to get bugs fixed is for the developers of
>> the code in question to be involved. Many Fedora maintainers help
>> facilitate this for users, which is awesome, but the sheer number of
>> bugs exceeds what even our large contributor community can address.
> 
> Contributions are usually not wanted, despite what all projects tell
> you.  I have given up trying to make any and keep things to myself
> instead.
> 
The issue I have here is even if I did file a bug, and the issue were 
fixed, no sooner than it's fixed fedora updates to the next version and 
introduces a whole bunch of new bugs, and so the cycle continues. I 
played that game for a while with fedora core when Red Hat Linux died 
before settling on Enterprise Linux and have never looked back.

I have just recently upgraded my main system from el5 to el7. I 
originally built and installed that el5 system back in 2007. It ran for 
10 years without a hitch. I can count the number of bugs I had to file 
in 10 years on one hand. Once they were fixed the system just worked for 
10 years. If RH continued to support it, I'd still be using it now, and 
probably for a lot longer, because it still worked as well for me now as 
it did in 2007. I've updated to el7 not because I wanted to or needed 
to, but because I was forced to, and given the pain I want another 10 
years of payback to make it worth the effort.
>> I know it sucks when an issue that affects you doesn't get fixed in
a
>> timely manner, but we really do appreciate reports and it's helpful
if
>> you can retest and reopen EOL bugs if they do indeed still happen in
>> the newer version.
> 
> It is discouraging to see bugs closed all the time not because the bugs
> are fixed but because Fedora has gone EOL again.  When the policy is to
> have bugs fixed upstream, it might be a good idea to have them reported
> upstream and to restrict Fedoras bugzilla to bugs actually introduced by
> Fedora.  In any case, I have given up reporting bugs a long time ago,
> especially with Fedora.
> 
> However, I?m seeing the same bugs from years ago still unfixed in Centos.
> That refers to libreoffice being unusably slow.  This still doesn?t seem
> to be fixed for Fedora, either, because it went EOL --- but I don?t know.
> 
Agree on that. My previous 10 year old el5 install ran OpenOffice 
perfectly on 10 year old hardware. My new el7 install on brand new 
hardware which is vastly superior in terms of processing power, GPU 
power, disk IO, can't even scroll a simple 3 column spreadsheet on the 
screen. How is that improvement or advancement?

But if the issue does ever get fixed, you can bet your life I'll be 
sticking with that fixed product for the next 10 years, not upgrading to 
some other broken version in 6 or 12 months time.
> What is the fix for Centos?  There used to be a package you could install
> which made libreoffice work at normal speed, and that package seems to
> have disappeared.
>

On Fri, Jul 28, 2017 at 10:11:53PM +0100, Phil Perry
wrote:
> The issue I have here is even if I did file a bug, and the issue
> were fixed, no sooner than it's fixed fedora updates to the next
> version and introduces a whole bunch of new bugs, and so the cycle
> continues. I played that game for a while with fedora core when Red
> Hat Linux died before settling on Enterprise Linux and have never
> looked back.
Sure; that's the tradeoff of getting new stuff.

But, I'm not asking anyone here to switch to Fedora. I'm asking
(especially those of you who are professional sysadmins) to please look
at the Modularity prototype.



-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader

On 07/28/2017 04:22 PM, Matthew Miller wrote:
> On Fri, Jul 28, 2017 at 10:11:53PM +0100, Phil Perry wrote:
>> The issue I have here is even if I did file a bug, and the issue
>> were fixed, no sooner than it's fixed fedora updates to the next
>> version and introduces a whole bunch of new bugs, and so the cycle
>> continues. I played that game for a while with fedora core when Red
>> Hat Linux died before settling on Enterprise Linux and have never
>> looked back.
> 
> Sure; that's the tradeoff of getting new stuff.
> 
> But, I'm not asking anyone here to switch to Fedora. I'm asking
> (especially those of you who are professional sysadmins) to please look
> at the Modularity prototype.
> 
> 
> 

I would like to point out that the next RHEL releases start as a Fedora
release which is branched off at some point in time, has some packages
removed (which the RHEL team deems not needed or unsupportable, etc.)
and then undergoes a process of testing, bug fixing, etc.

Testing and using Fedora is extremely helpful to the RHEL engineering
process, and since CentOS is a rebuild of the RHEL source code, the
CentOS engineering process.

I personally have a Fedora machine that I keep updated and do some work
on all the time learning/testing.  I just seamlessly upgraded it from
Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome
experience actually.

We don't have to pick sides here.  There is no reason not to run Fedora
alongside CentOS, it certainly allows you to understand where the next
CentOS releases will look like well before they are released.

Obviously looking at Fedora 26 and the new Modularity components will be
helpful for anyone who will be upgrading to newer RHEL or CentOS
releases in the future.

A big thank you to both Matthew and the entire Fedora team on another
quality release.  Not to mention the help that many Fedora team members
are providing in producing EPEL and also as members of the CentOS SIG
process.  All 3 of the distributions (Fedora, RHEL, CentOS) are better
because of this effort.

Thanks,
Johnny Hughes

-------------- 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/20170730/fabe6618/attachment-0001.sig>

Phil Perry wrote:
>> However, I?m seeing the same bugs from years ago still unfixed in
Centos.
>> That refers to libreoffice being unusably slow.  This still doesn?t
seem
>> to be fixed for Fedora, either, because it went EOL --- but I don?t
know.
>>
>
> Agree on that. My previous 10 year old el5 install ran OpenOffice perfectly
on 10 year old hardware. My new el7 install on brand new hardware which is
vastly superior in terms of processing power, GPU power, disk IO, can't even
scroll a simple 3 column spreadsheet on the screen. How is that improvement or
advancement?
>
> But if the issue does ever get fixed, you can bet your life I'll be
sticking with that fixed product for the next 10 years, not upgrading to some
other broken version in 6 or 12 months time.
Let me say just this:

I installed Libreoffice on one machine running Centos, and it was too slow to be
useable.  So I downloaded the rpm package from the Libreoffice website and
installed that version, and it works fine.

I installed Libreoffice on another machine with almost identical hardware,
running
the same version of Centos, and it works fine.

So I can only speculate that there might some package installed on one machine
which
isn?t installed on the other, and that package makes Libreoffice useable.  But
wich
package is that?

Matthew Miller wrote:
> On Fri, Jul 28, 2017 at 10:11:53PM +0100, Phil Perry wrote:
>> The issue I have here is even if I did file a bug, and the issue
>> were fixed, no sooner than it's fixed fedora updates to the next
>> version and introduces a whole bunch of new bugs, and so the cycle
>> continues. I played that game for a while with fedora core when Red
>> Hat Linux died before settling on Enterprise Linux and have never
>> looked back.
>
> Sure; that's the tradeoff of getting new stuff.
>
> But, I'm not asking anyone here to switch to Fedora. I'm asking
> (especially those of you who are professional sysadmins) to please look
> at the Modularity prototype.
Well, it might have some merits if it does work and makes its way into
Centos because with Centos, I?m finding myself unusually often needing a
more recent version of a package --- or something that isn?t packaged at
all --- than is installed by default.

That leaves to ask whether making it easier to require users to have a mess
of different versions of packages installed all at the same time or providing
more recent packages by default is the better solution.  Considering that
not providing sufficiently recent packages apparently comes from a fear of
breaking things, you need to explain how it is better to provide a mess of
different versions of packages by default because doing that appears to make
it easier to have things broken (by default), while making it much more
difficult for everyone to maintain the distribution and their machines.

So in the end, how does it NOT make things worse?  And that doesn?t even
mention the necessity to fix bugs found in outdated versions of software.
People might use them because they suddenly have become easy to install.

It COULD make things better when more recent packages could be installed
AND made the default, already because it is unwieldy having to take care of
using the right version of gcc and other things to compile software that isn?t
packaged, which is unwieldy to begin with because you also need to keep it up
to date.  So instead of providing more different versions of the same packages,
it might be better to package more different software.

Guess what, even nasm in Centos is outdated, and you have to enable yet another
repo to get the current version, or install it yourself.  That doesn?t go along
well with the overrated fear of breaking things, not one way, nor the other.

You could even say this multiversion thing is about providing a way of breaking
things, much like brokenarch was with Debian.