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

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.

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.

Of course, if you _really_ need something fixed and want someone on the
hook to do it for you, I suggest Red Hat's commercial offering.

> Now Fedora goes Gentoo, which I moved away from because of exactly
> what Fedora finally goes for.
This is nothing like Gentoo.

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

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

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.
> Of course, if you _really_ need something fixed and want someone on the
> hook to do it for you, I suggest Red Hat's commercial offering.
I usually end up finding another solution, perhaps fixing the problem
myself, or not having a solution at all.  And for example, I doubt that
RH would be inclined to come up with a CUPS filter that allows to print
files created with lyx directly because it?s not possible to use lyx to
convert them without running a GUI.
>> Now Fedora goes Gentoo, which I moved away from because of exactly
>> what Fedora finally goes for.
>
> This is nothing like Gentoo.
Sure is:  You get to manage your distribution yourself by picking the
versions of packages you figure might work together, which you are
supposed and required to do with Gentoo, especially when you run into
yet another dependency conflict.  Only --- I guess --- you don?t get
the same level of control over the packages as you get with Gentoo
because there aren?t any USE flags.

I understand that the idea is probably to make it so that you don?t
have problems like you can have with Gentoo because the packages are
isolated in such a way that there are no dependency conflicts.  So you
end up trying to figure out for every package which version you want and
which version brings about the minimum overhead you can get away with.
That is not substantially different from what you do with Gentoo in that
you are faced with having to find answers for questions you know you
shouldn?t need to ask in the first place.

In case I really need a particular version of some software, nothing
really prevents me from installing it myself.  It?s rare enough that
this happens.  In my case, that?s once in 30 years --- twice if you
count the perl version in Centos being too old, but that can be worked
around.

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?

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 Jul 28, 2017, at 1:56 PM, hw <hw at gc-24.de> wrote:
> 
>> 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.
With that attitude, nothing would ever be fixed.  I understand you are
frustrated, but feedback and bug reports are one of the best way to help open
source projects.


--
Jonathan Billings <billings at negate.org>

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>

On Fri, Jul 28, 2017 at 07:56:41PM +0200, hw wrote:
> Sure is:  You get to manage your distribution yourself by picking the
> versions of packages you figure might work together, which you are
> supposed and required to do with Gentoo, especially when you run into
> yet another dependency conflict.  Only --- I guess --- you don?t get
> the same level of control over the packages as you get with Gentoo
> because there aren?t any USE flags.
No, this isn't it it all. Modules are sets of packages which the
distribution creators have selected to work together; you don't compose
modules as an end-user. 

> 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? 
This is a false dichotomy. We will be providing a stable platform as
the Base Runtime module.

> 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 can't speak to Red Hat plans or Red Hat fixes. In Fedora, we might
have, say, squid 3.5, squid 4.0, and squid 5 streams (stable, beta, and
devel) all maintained at the same time.



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

On Jul 28, 2017, at 11:56 AM, hw <hw at gc-24.de>
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.
> 
> Contributions are usually not wanted, despite what all projects tell
> you.
The main reason contributions are rejected at the level of this mailing list is
that they?re being offered at the wrong level.

CentOS is really hard to fix directly, because virtually none of the work
product of the CentOS maintainers goes into writing or patching the software
that is distributed.  Fixes need to happen at the upstream levels: RHEL, Fedora,
or the individual software project.

This list is mainly about using CentOS as we find it today, not about driving
its future, because its future is largely driven by the upstreams.

If you?ve been trying to get fixes into the upstream software projects, then I
can tell you as the lead maintainer of a few open source software projects and
contributor to many others, there are many good reasons not to accept random
drive-by patches:

1. No license given.  This may mean no contributor agreement was signed for
projects that require it, or simply no explicit license on the contributed
files.  The default in the civilized world is full copyright, all rights
reserved, so you can?t just put a set of changes online and expect others to
merge them into the official source base.

2. ABI breakage.  Many projects restrict any change that would break an ABI to
major version transitions.

3. API breakage.  If the project is a library, you generally can only add new
interfaces, not remove or change existing ones, except at major version
transitions.

4. Does not build on all target systems, no tests, patch doesn?t apply cleanly
to the development branch, bad code formatting, poor variable naming, etc.  Some
projects will take a half-assed patch and do the finishing work on it for you,
but not all will.

5. Philosophy mismatch.  If your patch changes how something behaves and that
behavior change doesn?t match how the project maintainer wants things to work,
you?re probably stuffed.  Quite frankly, your opinion doesn?t matter as much as
that of the person who designed the system and has been maintaining it for the
last N years.  As long as that person holds well-regarded opinions, his project
is likely to remain unforked, and your contribution will remain disregarded.

I can summarize all of the above with, ?It?s difficult to work with other
people,? but that?s no particular failing of open source software.  That?s just
people.