Re: Fedora 30 EOL
On Mon, 1 Jun 2020 12:09:36 -0500, Roger Heflin wrote: > When the policy is not being followed and/or not enforced it means > nothing. Only someone who is in love with > the policy would say otherwise and actively defend it. You're still not getting it. > I am going to guess you helped write large parts of the policy > and that is why you defined it. ??? > Yes, lets enforce the policy against > the everyone until you have no community. See above. You're not getting it. You talk about "enforcing" something, you preach stagnation. That isn't helpful and not a way forward for Fedora. > Since there are packages going unmaintained it not like they are that > easily replaceable. ??? > It is you as a "insider" > that seems to be denying the "perfect" policy is not functioning as > often as you like and not admitting that it can > be made to work with the staff you had. If the maintainer for the > kernel package is not following it, > I doubt many are following it. Please stop guessing. It can't generalized like that. Quite obviously, there are _many_ packages that are much easier to maintain than the kernel package (with its ticket linked earlier in this thread). There are different aspects of maintenance. Handling bug reports is just one of many tasks. > And while you are calling me an outsider, I have been using what > became fedora for years before the first fedora > version was released, and have been using it almost every version since then. The question about your "background" was necessary because it becomes apparent that you comment on things as one who either doesn't know how things work at the Fedora Project (or how things are supposed to work) or you deliberately ignore it. You don't seem to care about project policies and guidelines, and you brush aside what's there as a base. You even ignore what different levels of maintenance are needed for different packages. > On the fedora side we should probably be directing anyone with > software bugs to upstream. Should? Probably? And you expect upstream to not be understaffed, especially not if being flooded with bug reports which may be distribution-specific? > Don't get me started about [...] Thread is closed for me. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
When the policy is not being followed and/or not enforced it means nothing. Only someone who is in love with the policy would say otherwise and actively defend it. I am going to guess you helped write large parts of the policy and that is why you defined it. Yes, lets enforce the policy against the everyone until you have no community. Since there are packages going unmaintained it not like they are that easily replaceable. It is you as a "insider" that seems to be denying the "perfect" policy is not functioning as often as you like and not admitting that it can be made to work with the staff you had. If the maintainer for the kernel package is not following it, I doubt many are following it. And while you are calling me an outsider, I have been using what became fedora for years before the first fedora version was released, and have been using it almost every version since then. On the fedora side we should probably be directing anyone with software bugs to upstream. I am going to guess that the guidelines were copied from the enterprise side where they are maintaining packages that are years behind upstream, were as fedora would rarely be in that position, and it would be best to direct them to upstream. And then create a BZ to backport a patch and/or uplift to the new version. Getting the package maintainer in the middle seems to only add either failure or at best friction to the process. Setting the standards too high removes viable resources of people that may have just retired from a job and don't want a job with hard defined guidelines. Don't get me started about generally negative value automated response from the PAID distribution vendors, they seem to be an extension of the generally worthless process were the exact same information is asked to be collected for each bug for it to progress to the next level, even if that information is not pertinent to the given bug. The automation does not solve the problem, it only pisses everyone off more with its negative value added messages, and arbitrary requirements that may have no useful reason to be done for the bug in question. The distribution vendors love sosreport for anything even for clear bugs that an sosreport is useless. On Sun, May 31, 2020 at 3:14 AM Michael Schwendt wrote: > > On Sat, 30 May 2020 16:42:10 -0500, Roger Heflin wrote: > > > The policy means nothing when > > Only an "outsider" would say that. That policy has been refined multiple > times since the fedora.us era with its strict QA policies. That policy is > also reason why potential "maintainers" shy away from the community > project, because as volunteers they can't tell whether they would be able > to meet the requirements. I could point you at the related "non-responsive > maintainer policy", but so far you aren't listening. > > > the staffing is not there to actually do the tasks. > > Sweet how you try to dance around the problem. Where bugzilla components > are literally flooded with tickets, automation would be the way to go. > That has been pointed out before. Meaningful, early responses that give > bug reporters some guidance on where and how they could escalate an issue, > where they could discuss an issue in order to gather more details and to > confirm a problem, and and and. > > > And clearly there is limited staffing. And if they are a volenteer > > then tell them they arent doing their job and kick them out. Repeat until > > there is no community and you have no staff. > > Key components are still maintained by Red Hat. That is an essential and > important contribution to this project. Offer a distribution that doesn't > satisfy users, and you lose (or reduce) the user part of the community > including most of the guinea pigs. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Sat, 30 May 2020 16:42:10 -0500, Roger Heflin wrote: > The policy means nothing when Only an "outsider" would say that. That policy has been refined multiple times since the fedora.us era with its strict QA policies. That policy is also reason why potential "maintainers" shy away from the community project, because as volunteers they can't tell whether they would be able to meet the requirements. I could point you at the related "non-responsive maintainer policy", but so far you aren't listening. > the staffing is not there to actually do the tasks. Sweet how you try to dance around the problem. Where bugzilla components are literally flooded with tickets, automation would be the way to go. That has been pointed out before. Meaningful, early responses that give bug reporters some guidance on where and how they could escalate an issue, where they could discuss an issue in order to gather more details and to confirm a problem, and and and. > And clearly there is limited staffing. And if they are a volenteer > then tell them they arent doing their job and kick them out. Repeat until > there is no community and you have no staff. Key components are still maintained by Red Hat. That is an essential and important contribution to this project. Offer a distribution that doesn't satisfy users, and you lose (or reduce) the user part of the community including most of the guinea pigs. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Having started with RH 5.1, and now on Fedora 31, I find this thread enlightening, entertaining, and relevant. On Sat, 30 May 2020 at 17:19, Kevin Becker wrote: > > When is this thread scheduled for EOL? > > > On Sat, 2020-05-30 at 18:44 +0200, Michael Schwendt wrote: > > On Sat, 30 May 2020 11:14:22 -0500, Roger Heflin wrote: > > > You really need to understand the devs actual motivations. And your > > are attributing things to Fedora devels that are being funded outside > > of the Fedora community. > > > Please, think outside the box. It isn't helpful to the discussion, if > > you are stuck with your own guesswork of how it may or may not work on > > the distribution maker's side. There are actual policies! > > https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ > > > ___ > > users mailing list -- > > users@lists.fedoraproject.org > > > To unsubscribe send an email to > > users-le...@lists.fedoraproject.org > > > 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/users@lists.fedoraproject.org > > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org -- Stephen E. Perkins, RN Poetry and Community Health RuralTechnologies.net Linux since Red Hat 5.1, 1998 Open-source CollaborationFedora since 2003 “With credulity come propaganda and advertising to dupe the citizen with political jobbery and compromises, and the lie reaches proportions never known before in the history of the world.” – C. G. Jung, The Undiscovered Self (1957) -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
The policy means nothing when the staffing is not there to actually do the tasks. And clearly there is limited staffing. And if they are a volenteer then tell them they arent doing their job and kick them out. Repeat until there is no community and you have no staff. Policy is theory of what should be done, no one ever staffs anything to actually follow the policy fully, so things get dropped. On paid we always get responses in a timely manner, but we are paying for that and have a sla. And often the response is wont fix for one reason or the other. On Sat, May 30, 2020, 11:45 AM Michael Schwendt wrote: > On Sat, 30 May 2020 11:14:22 -0500, Roger Heflin wrote: > > > You really need to understand the devs actual motivations. And your > > are attributing things to Fedora devels that are being funded outside > > of the Fedora community. > > Please, think outside the box. It isn't helpful to the discussion, if > you are stuck with your own guesswork of how it may or may not work on > the distribution maker's side. There are actual policies! > > https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
When is this thread scheduled for EOL? On Sat, 2020-05-30 at 18:44 +0200, Michael Schwendt wrote: > On Sat, 30 May 2020 11:14:22 -0500, Roger Heflin wrote: > > You really need to understand the devs actual motivations. And > > yourare attributing things to Fedora devels that are being funded > > outsideof the Fedora community. > > Please, think outside the box. It isn't helpful to the discussion, > ifyou are stuck with your own guesswork of how it may or may not work > onthe distribution maker's side. There are actual policies! > https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ > ___users mailing list -- > users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Sat, 30 May 2020 11:14:22 -0500, Roger Heflin wrote: > You really need to understand the devs actual motivations. And your > are attributing things to Fedora devels that are being funded outside > of the Fedora community. Please, think outside the box. It isn't helpful to the discussion, if you are stuck with your own guesswork of how it may or may not work on the distribution maker's side. There are actual policies! https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
You really need to understand the devs actual motivations. And your are attributing things to Fedora devels that are being funded outside of the Fedora community. Lenovo will be supporting Fedora on their laptops. They are the OEM and will provide the heavy lifting (with enterprise distributions this is also exactly how it works, the dist vendors *EXPECT* the hardware vendors to provide the heavy lifting and code. When the OEM's submit something to BZ it likely will be a fully done patch, Fedora is not "supporting" anything formally, that is unless lenovo is funding people explicitly for that.They are very likely acting as kernel developers and/or application developers for the software needed to support their hardware. This is how almost all the hardware drivers come to be written. The vendor making it writes the drivers, not generic devs paid by a distribution vendor unless it is in the distribution vendors self-interest to do so to support a large paying client. And both the radeon and nouveau drivers are being done by kernel devs that are at most only associated with Fedora. If you look up some of the various devels they are working for Companies that are using the hardware themselves internally and are funding the work, or for the companies that provide the hw. They have their own self-interest that just happens to help you. This is how the entire open source community was built, most contributers have their own self-interest first and that self-interest may or may not help you. They did not do secure boot for the reasons for free distribution Fedora. They did secure boot because a number of their paid enterprise customers require it for some of their environments. And the exact same with UEFI, a number of the enterprise customers must have UEFI, as legacy is going away. The failed Itanium hardware that existed in 2003-2010 or so was EFI boot only. Certain government contracts also require secure boot, hence those projects got funded. On Sat, May 30, 2020 at 9:11 AM Suvayu Ali wrote: > > On Sat, May 30, 2020 at 12:34 PM Roger Heflin wrote: > > > those workstations would be the expensive cards. A yearly redhat > > support license is enough that no one is going to buy one for a $1000 > > machine because in 3 years that license will cost more than the HW, so > > the "cheap" hardware that is being discussed like any of us would use > > isn't something they will likely run into in the enterprise market. > > There is a significant amount of HW used on this list that they simply > > will never be supporting on the enterprise end. > > You really need to keep up. For many years Fedora devs (kernel, and > bios) have spearheaded the effort to make Linux in general, and Fedora > specifically a priority on desktops and laptops. Tremendous amount of > work went into the kernel and UEFI compatibility, particularly the way > M$ was pushing for "secure boot". So much so, Fedora kernels were > controversially secure boot compatible earlier due to a (digital) > signing agreement with M$. Fedora has also contributed significantly > in making FOSS radeon drivers reliable, and advanced noveau despite > hostility from NVidia. > > As for recent developments, if Fedora doesn't want to support regular > installs, how come ThinkPads are going to be shipped by Lenovo with > Fedora pre-installed? > > https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/ > > And you still haven't read the BZ I linked in my OP, and going on and > on about hypothetical scenarios. Please inform yourself better. > > -- > Suvayu > > Open source is the future. It sets us free. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Sat, 30 May 2020 07:33:04 -0500, Roger Heflin wrote: > My background is I have been used Fedora since Core 1, and prior to > that started with Redhat 5/6/7/8/9 and managed (or was technical lead > for a team) with >1000 installed running combinations of RHEL, Centos, > non-enterprise Redhat/Fedora, and/or SLES since around 1998, in > addition to running a few home systems. So, that confirms my assumption. For reasons not known yet you ignore why non-commercial Linux distributions exist and how they try to appeal to a potential target audience. That is really odd, because you have been a distribution user already when Red Hat Linux was not a community project yet and only offered unsatisfying experiments like Red Hat Contrib before the creation of the independent fedora.us project. > The distribution also remove a signification number of rpms so only > cares about supporting maybe 1/2 or less (and that is for the rpms in > the fedora repos). ??? Where do your numbers come from? Even old Red Hat Linux doubled its number of source (!) packages from 4.x to 8.0. And the size of the package collection (in terms of source rpms) has grown a lot to something like factor 30-50 with/without taking into account 3rd party repositories. > A lot of single reporter bugs are often something specific odd the > person is doing wrong, and it takes a lot of time to work through the > reports to figure out which are which. Which is not the point. The point is that submitted bug reports (particularly those that have been commented on by the bug reporter instead of only dumping data into bugzilla via ABRT) ought not end up in nirvana. And if somebody decides that it's a corner-case issue with nobody to look into it due to insufficient manpower, the automated response could offer some guidance for the bug reporter. > I don't believe abrtd collects kernel panic by default, and kernel > dumps also aren't configured by default. Have you never noticed the "[abrt]" prefix in the bug summaries? https://bugzilla.redhat.com/buglist.cgi?component=kernel&product=Fedora ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Sat, May 30, 2020 at 12:34 PM Roger Heflin wrote: > those workstations would be the expensive cards. A yearly redhat > support license is enough that no one is going to buy one for a $1000 > machine because in 3 years that license will cost more than the HW, so > the "cheap" hardware that is being discussed like any of us would use > isn't something they will likely run into in the enterprise market. > There is a significant amount of HW used on this list that they simply > will never be supporting on the enterprise end. You really need to keep up. For many years Fedora devs (kernel, and bios) have spearheaded the effort to make Linux in general, and Fedora specifically a priority on desktops and laptops. Tremendous amount of work went into the kernel and UEFI compatibility, particularly the way M$ was pushing for "secure boot". So much so, Fedora kernels were controversially secure boot compatible earlier due to a (digital) signing agreement with M$. Fedora has also contributed significantly in making FOSS radeon drivers reliable, and advanced noveau despite hostility from NVidia. As for recent developments, if Fedora doesn't want to support regular installs, how come ThinkPads are going to be shipped by Lenovo with Fedora pre-installed? https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/ And you still haven't read the BZ I linked in my OP, and going on and on about hypothetical scenarios. Please inform yourself better. -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Sat, May 30, 2020 at 7:41 AM John M. Harris Jr wrote: > Yes, the other option would be to move to Debian or find another rpm-based > distro that still supports 32 bit. All of this because Fedora decided to do > what seems to be so common recently, dropping what still works well. This > hurts our community. This hurts our users. It'd be one thing to make it so > that QA requirements were effectively dropped on 32 bit, but there was no real > reason to drop 32 bit support. It still worked, and quite well. If I recall correctly, the biggest "user burden" for 32-bit packages was load on people who maintain Fedora mirrors. -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Hi Bruno, On Sat, May 30, 2020 at 3:11 AM Bruno Wolff III wrote: [...] > I think that covers most of it. It isn't really as bad as it looks > written out. Thank you so much for sharing it! I can work with this, maybe some of it could also be automated leveraging copr ;) -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Sat, May 30, 2020 at 00:40:27 -0700, "John M. Harris Jr" wrote: Yes, the other option would be to move to Debian or find another rpm-based distro that still supports 32 bit. All of this because Fedora decided to do what seems to be so common recently, dropping what still works well. This hurts our community. This hurts our users. It'd be one thing to make it so that QA requirements were effectively dropped on 32 bit, but there was no real reason to drop 32 bit support. It still worked, and quite well. It didn't work well in general, though it may have worked well for you. It has been getting more difficult to support i686 in the kernel over time. There were very few people willing to help Fedora's kernel maintainers with bugs in i686 kernels. They asked for help multiple times over more than a year and they didn't get a significant amount of help. If you want you go back and find the threads covering these requests. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
My background is I have been used Fedora since Core 1, and prior to that started with Redhat 5/6/7/8/9 and managed (or was technical lead for a team) with >1000 installed running combinations of RHEL, Centos, non-enterprise Redhat/Fedora, and/or SLES since around 1998, in addition to running a few home systems. The distribution maker has very little footprint in graphics workstations and/or simply workstations on the paid end. The graphics workstations they do support the video drivers would be supported directly by the graphics vendor as the cards being used on those workstations would be the expensive cards. A yearly redhat support license is enough that no one is going to buy one for a $1000 machine because in 3 years that license will cost more than the HW, so the "cheap" hardware that is being discussed like any of us would use isn't something they will likely run into in the enterprise market. There is a significant amount of HW used on this list that they simply will never be supporting on the enterprise end. The distribution also remove a signification number of rpms so only cares about supporting maybe 1/2 or less (and that is for the rpms in the fedora repos). A lot of single reporter bugs are often something specific odd the person is doing wrong, and it takes a lot of time to work through the reports to figure out which are which. I don't believe abrtd collects kernel panic by default, and kernel dumps also aren't configured by default.And for the bugs I have submitted a core dump to the paid distribution vendor the core dump was useful 1 out of 10 times they ask for it. The issues it did help with took the better part of a year and the major version we found the issue on was EOL, but the "bug" was known to be in the next major version so at least was fixed there, And kernel.org will not accept a kernel bug from a non-kernel.org kernel because too often the distributions have patched the code in some significant way and that caused the issue. If you want a kernel bug fixed you are going to have to do a significant amount of work. Even with the paid vendor you will be doing a significant amount of work to fix almost anything even if you can document all of the details and point to a code fix. If you need technical help to get them the data they are being paid to provide that, on the free size they aren't paid for that, and it can be a significant amount of work. And from what I can tell all of the other distributions work with the exact same model, the major difference between the distributions seems to be staffing level based on how many licenses they sell. The free BZ I got response on, had all of the details including documenting the bug and the exact code fix. On Sat, May 30, 2020 at 3:43 AM Michael Schwendt wrote: > > On Fri, 29 May 2020 21:08:10 -0500, Roger Heflin wrote: > > > The maintainers are for the most part about "packaging" kernels. > > They rarely seem to ever work on kernel bugs, nor have the time to do > > such investigate even if they have the time. > > If that were true, something would be even more wrong in Fedora land, > since in that case ABRT ought not point at bugzilla.redhat.com by default > for kernel issues. Last time I had a look, Fedora's kernel package > included around a hundred patches. Fedora's kernel is also where things > are tested for RHEL, and therefore any problem report could serve as an > early warning. > > > They are not here to answer you questions, and they are overworked. > > If someone is paying them, whoever that is, is setting their > > priorities and their priorities are not to do their job. If they > > aren't paid well then if they help some ok, but no one is owed a > > response. > > ??? I don't know your background with regard to the Fedora Project, but > what you write here makes no sense from a distribution maker's perspective. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Fri, 29 May 2020 21:08:10 -0500, Roger Heflin wrote: > The maintainers are for the most part about "packaging" kernels. > They rarely seem to ever work on kernel bugs, nor have the time to do > such investigate even if they have the time. If that were true, something would be even more wrong in Fedora land, since in that case ABRT ought not point at bugzilla.redhat.com by default for kernel issues. Last time I had a look, Fedora's kernel package included around a hundred patches. Fedora's kernel is also where things are tested for RHEL, and therefore any problem report could serve as an early warning. > They are not here to answer you questions, and they are overworked. > If someone is paying them, whoever that is, is setting their > priorities and their priorities are not to do their job. If they > aren't paid well then if they help some ok, but no one is owed a > response. ??? I don't know your background with regard to the Fedora Project, but what you write here makes no sense from a distribution maker's perspective. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Fri, 29 May 2020 13:56:34 -0500, Roger Heflin wrote: > I don't believe the kernel.org developers work out of the fedora > bugzilla (or any distro's bugzilla), so no one who knows anything is > likely to find and/or see the bug. > > To get a kernel developer you would need to at least post a summary to > the kernel subsystem list if you know which subsystem or the main > kernel if you don't. This makes no sense, given that Fedora introduced ABRT, the automatic bug reporting tool. Distribution users enter their crash reports into the distribution's bug tracker, of course, assuming it is the primary point of contact and that bug reports are appreciated and won't be lost. And in this case, the bug reporter didn't only dump an uncommented backtrace into bugzilla. > And the kernel.org guys do not care about any testing done on a fedora > delivered kernel as they don't know what code is in it, so you would > need to install a kernel.org kernel and bot from it and verify you > have the issue on the newest released one. ??? Which is why Fedora users assume that Fedora developers know the right thing to do in case of problems, such as suggesting that it could be fruitful to discuss a problem on some specific mailing-list or where to report it instead. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thursday, May 28, 2020 10:46:18 PM MST Samuel Sieb wrote: > On 5/28/20 9:19 PM, John M. Harris Jr wrote: > > > It's quite possible that Suvayu Ali is one of the many users that cannot > > install Fedora 31, because it doesn't work on their hardware. Fedora 30 > > was the last release to support i686, so many users are now stuck there > > forever, unless they move to another distro entirely. > > > If it's a 32-bit issue then it has become irrelevant anyway since that > is no longer supported in Fedora. I fail to see how. That Fedora doesn't support it anymore doesn't mean that these situations stopped existing. > I have a computer mounted on my wall that used to run Fedora. It has a > Cyrix Geode processor and a few years ago Fedora was no longer suitable > for it. I didn't fuss at Fedora about that, technology moves on. I > switched to buildroot instead, which works much better. Technology has not "moved on". These systems are still completely viable, they're just not supported by Fedora anymore. > Please accept that the decision has been made and other major distros > are doing the same. Stop bringing it up all the time. If you really > have a device that can only do 32-bit, there are still other options. Yes, the other option would be to move to Debian or find another rpm-based distro that still supports 32 bit. All of this because Fedora decided to do what seems to be so common recently, dropping what still works well. This hurts our community. This hurts our users. It'd be one thing to make it so that QA requirements were effectively dropped on 32 bit, but there was no real reason to drop 32 bit support. It still worked, and quite well. -- John M. Harris, Jr. Splentity ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Fri, May 29, 2020 at 23:24:58 +, Suvayu Ali wrote: Could you please share your workflow? I have been looking for some guidance so that I can test upstream kernels when I encounter these hardware issues. I don't need step by step instructions, I'm very comfortable compiling software, I just need some way to manage the self-compiled kernels alongside Fedora kernels without littering my system with build artifacts, and play nice with SELinux :). I typically limit any software I compile myself to /opt or $HOME; unfortunately that doesn't quite work with kernels :-p Usually once I decide that it is worth doing a bisect, I'll mention that I'm working on doing a bisect in my Fedora bug report. Then I get Linus' tree. Either doing a git pull if I have an existing one or a git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git if I don't. Sometimes if the checkout was in a bad state, git pull won't update and it's easier to do a clone rather than figure out what is messed up. Next I copy over a Fedora kernel config file into the checkout. A sample would look like the following if I was in the top directory of the checkout: cp /boot/config-5.7.0-0.rc7.1.fc33.x86_64 .config In theory the differencs in the Fedora kernel and Linus' could cause a problem, but normally it won't. Then I do a make clean all. Once you get close on the bisect you don't really need to do a clean and it can speed things up a lot to skip it. You will probably get asked about some configuration options, because of differences between your checked out version and the Fedora kernel. Usually just using the default works. Then you need to switch to root. When you install kernels, files are going to get added to /boot and a directory is going to get added to /lib/modules . You are going to want to clean those up (but make sure you don't clean up stuff for the running kernel) before doing the next install to make sure you are running what you think you are when you run the test. Then you want to do: make modules_install install If all of the above works, you can reboot to test the new kernel. You probably want to have a short delay set in grub to allow you to easily pick which kernel you want to boot. So if the the problem is still in the upstream kernel, then you'll want to start the bisect. In the checkout (which should be the broken latest Linus kernel) do the following: git bisect start git bisect bad Then you want to set the checkout to be some point in the tree that did not have the problem you are testing for. The closer the the bug, the fewer steps you will need to bisect the issue. You either need a git commit hash or a version tag and do git reset --hard to checkout the next kernel to test. Then you build and test stuff as above. If the test fails then you run git bisect bad. If it succeeds then you run git bisect good. Generally once you have a good and a bad kernel, you won't want to manually checkout a particular commit. The last git bisect command will have checked out a version roughly half way between the latest good version and the earliest bad version you have seen so far. Sometimes there can be issues with test kernels and you may have to manually checkout a different version to jump around them. You keep doing this until you find the commit that triggered the issue. Then you can do git bisect log to get the list of tested kernels and save that, so you can restart part way through if needed. Then use git bisect reset to clean up the bisect stuff. Sometimes, you can confirm the problem commit by starting at the latest Linus kernel and do a git revert of the problem commit. That won't always work if there is other stuff dependent on that commit. Then you can note the in the Fedora bug. At this point it also makes sense to report the issue upstream. You'll want to look at the bug and try to guess which subsystem is involved and post to the subsystem list and copy the main kernel list. People will normally assume you're off list when replying, so you don't need to subscribe to the list to follow the discussion. Upstream might ask you to test fixes. Once upstream is fixed, you can wait for the next rawhide kernel build to test the fix for Fedora. Usually you can run rawhide kernels on other Fedora versions. This is useful for testing when you don't normally run rawhide and if you don't want to wait for the fix to get back ported to older kernel releases. It's possible one of the Fedora maintainers could do a backport if warranted. If they do, you'd want to do early testing of updates to make sure the bug is really fixed. I think that covers most of it. It isn't really as bad as it looks written out. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-condu
Re: Fedora 30 EOL
The maintainers are for the most part about "packaging" kernels. They rarely seem to ever work on kernel bugs, nor have the time to do such investigate even if they have the time. They are not here to answer you questions, and they are overworked. If someone is paying them, whoever that is, is setting their priorities and their priorities are not to do their job. If they aren't paid well then if they help some ok, but no one is owed a response. Looking at your above bug you filed that went well, and the comments, the above bug was duplicated by a number of people and that moves its priority up in the stack. It was also trivial to duplicate and did not required any special hardware and/or setup. it is a likely easy to fix bug. They like easy bugs. Any bug that looks hard and/or are not duplicated by others are going to get a pass and that is the simply the way it works. For the most part you must help yourself. If the bug is in any way complicated the goal of the support analyst is not to help you but to make you go away (and this is when you have a contract with a company and are paying big money). Without your paying they don't have any reason to waste your time by replying and asking you endless questions on something they have no idea about. The only SLA they seem to have is to find all of bz on EOL products and respond and close them. The rest of the community will help you when they have time, they do not owe you anything, and be happy that sometimes someone is willing to help you.And don't bitch about not getting a response, there is no requirement that anyone responds to any post you make, you are owed nothing. The fact that you seem to think you deserve a response would seem to indicate a lack of understanding of a "community". The comments on this thread about how to fix the issues by removing packages from being maintained seems that many just don't get that and they think they are owed something. You can argue that reality of how the community works should be different, but at the end of the day that would not be a community with each member having their own self-interests that sometimes allow them to help you. On Fri, May 29, 2020 at 6:41 PM Suvayu Ali wrote: > > On Fri, May 29, 2020 at 6:57 PM Roger Heflin wrote: > > > > I don't believe the kernel.org developers work out of the fedora > > bugzilla (or any distro's bugzilla), so no one who knows anything is > > likely to find and/or see the bug. > > > > To get a kernel developer you would need to at least post a summary to > > the kernel subsystem list if you know which subsystem or the main > > kernel if you don't. > > > > And the kernel.org guys do not care about any testing done on a fedora > > delivered kernel as they don't know what code is in it, so you would > > need to install a kernel.org kernel and bot from it and verify you > > have the issue on the newest released one. > > I wish people read the thread or even posts carefully before > responding. I'm well aware that kernel developers are not watching > the Redhat BZ, but the maintainers are. > > Anyway, here's an example of a healthy exchange on BZ: > > - I reported this bug on Tuesday: > https://bugzilla.redhat.com/show_bug.cgi?id=1840432 > - There was some discussion > - Today it got marked as a duplicate of this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1840780 > - The maintainer had commented on the second bug on Wednesday that he > is too busy, and unlikely to find time to investigate > - On Thursday another person dug through the upstream repo, found the > commit that fixes the issue, determined that simply updating to the > latest version from upstream would fix the crash, and as a bonus > pointed to the underlying reason that caused the crash. > - Earlier today the maintainer did a scratch build of the latest > release, and asked for testing > - I happened to be online, after testing I responded that the build works > - Quite likely there will be a new release next week that pushes out the > update. > > -- > Suvayu > > Open source is the future. It sets us free. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Fri, May 29, 2020 at 6:57 PM Roger Heflin wrote: > > I don't believe the kernel.org developers work out of the fedora > bugzilla (or any distro's bugzilla), so no one who knows anything is > likely to find and/or see the bug. > > To get a kernel developer you would need to at least post a summary to > the kernel subsystem list if you know which subsystem or the main > kernel if you don't. > > And the kernel.org guys do not care about any testing done on a fedora > delivered kernel as they don't know what code is in it, so you would > need to install a kernel.org kernel and bot from it and verify you > have the issue on the newest released one. I wish people read the thread or even posts carefully before responding. I'm well aware that kernel developers are not watching the Redhat BZ, but the maintainers are. Anyway, here's an example of a healthy exchange on BZ: - I reported this bug on Tuesday: https://bugzilla.redhat.com/show_bug.cgi?id=1840432 - There was some discussion - Today it got marked as a duplicate of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1840780 - The maintainer had commented on the second bug on Wednesday that he is too busy, and unlikely to find time to investigate - On Thursday another person dug through the upstream repo, found the commit that fixes the issue, determined that simply updating to the latest version from upstream would fix the crash, and as a bonus pointed to the underlying reason that caused the crash. - Earlier today the maintainer did a scratch build of the latest release, and asked for testing - I happened to be online, after testing I responded that the build works - Quite likely there will be a new release next week that pushes out the update. -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Hi Bruno, On Fri, May 29, 2020 at 7:59 PM Bruno Wolff III wrote: > > I occasionally submit kernel bug reports. These days one good way to > get your report looked at is to bisect a Linus kernel to find the commit > that triggered the problem. This normally takes me about a week to get > done. I have gotten fixes for bugs that affected old hardware that was in > limited use by other people. It isn't that hard to do, but kernel builds can > take a while and you need to be able to reboot for each test and there can > be limitations on when that can get done. Could you please share your workflow? I have been looking for some guidance so that I can test upstream kernels when I encounter these hardware issues. I don't need step by step instructions, I'm very comfortable compiling software, I just need some way to manage the self-compiled kernels alongside Fedora kernels without littering my system with build artifacts, and play nice with SELinux :). I typically limit any software I compile myself to /opt or $HOME; unfortunately that doesn't quite work with kernels :-p -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Fri, May 29, 2020 at 14:32:10 +, Suvayu Ali wrote: What baffles me most, is the nature of the bug. It is the text book case of a high priority bug, new (budget) hardware, which is becoming common place very fast, where Fedora isn't bootable, add to that it is a regression bug. How does a bug with these characteristics not come within the peripheral vision of the maintainers, specially when the reporter is eager to do all kinds of troubleshooting and testing!? Clearly something is wrong with the automation, the question is. how should that be fixed? I occasionally submit kernel bug reports. These days one good way to get your report looked at is to bisect a Linus kernel to find the commit that triggered the problem. This normally takes me about a week to get done. I have gotten fixes for bugs that affected old hardware that was in limited use by other people. It isn't that hard to do, but kernel builds can take a while and you need to be able to reboot for each test and there can be limitations on when that can get done. I run developmental kernels, so I'm likely to see bugs before others. Getting the problem noticed upstream before a kernel is released seems to also increase the odds of someone taking interest in it. For issues before rc1, I just usually note the issue in a Fedora bug so that others can notice that others are seeing the same thing. But enough of these get fixed by rc1 that it usually isn't worth it for me to go through the trouble of bisecting until after rc1 is released. (That will change with some newer hardware I'm putting together that will build kernels for that machine in a lot less time.) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
I don't believe the kernel.org developers work out of the fedora bugzilla (or any distro's bugzilla), so no one who knows anything is likely to find and/or see the bug. To get a kernel developer you would need to at least post a summary to the kernel subsystem list if you know which subsystem or the main kernel if you don't. And the kernel.org guys do not care about any testing done on a fedora delivered kernel as they don't know what code is in it, so you would need to install a kernel.org kernel and bot from it and verify you have the issue on the newest released one. On Fri, May 29, 2020 at 9:33 AM Suvayu Ali wrote: > > Hi Michael, > > On Thu, May 28, 2020 at 5:30 PM Michael Schwendt wrote: > > > > On Thu, 28 May 2020 18:08:48 +0930, Tim via users wrote: > > > > > Perhaps there should be an automated culling of participants. If you > > > step up the plate to say you'll maintain a package, but don't, *you* > > > get dumped from bugzilla. > > > > Please let's not create a thread of doom. > > > > You can't seriously suggest blocking kernel maintainers from bugzilla just > > because they don't have the manpower to take a look at every ticket and > > perform meaningful, helpful triaging. Some key components are literally > > flooded with bug reports. In order to deal with the number of tickets, > > using scripts is an obvious thing to do. Yet it isn't done in a proper and > > OS user-friendly way. > > I agree, this is exactly the case (I'm the OP, and the person who > filed the BZ referenced earlier). There should be clear guidance how > a motivated user can follow through, do the relevant triaging, and > maybe even test an upstream kernel, In fact if you read the BZ, > you'll see that I tried vanilla RC kernels from Thorsten's repo and > reported back to the BZ. > > What baffles me most, is the nature of the bug. It is the text book > case of a high priority bug, new (budget) hardware, which is becoming > common place very fast, where Fedora isn't bootable, add to that it is > a regression bug. How does a bug with these characteristics not come > within the peripheral vision of the maintainers, specially when the > reporter is eager to do all kinds of troubleshooting and testing!? > Clearly something is wrong with the automation, the question is. how > should that be fixed? > > -- > Suvayu > > Open source is the future. It sets us free. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Hi Michael, On Thu, May 28, 2020 at 5:30 PM Michael Schwendt wrote: > > On Thu, 28 May 2020 18:08:48 +0930, Tim via users wrote: > > > Perhaps there should be an automated culling of participants. If you > > step up the plate to say you'll maintain a package, but don't, *you* > > get dumped from bugzilla. > > Please let's not create a thread of doom. > > You can't seriously suggest blocking kernel maintainers from bugzilla just > because they don't have the manpower to take a look at every ticket and > perform meaningful, helpful triaging. Some key components are literally > flooded with bug reports. In order to deal with the number of tickets, > using scripts is an obvious thing to do. Yet it isn't done in a proper and > OS user-friendly way. I agree, this is exactly the case (I'm the OP, and the person who filed the BZ referenced earlier). There should be clear guidance how a motivated user can follow through, do the relevant triaging, and maybe even test an upstream kernel, In fact if you read the BZ, you'll see that I tried vanilla RC kernels from Thorsten's repo and reported back to the BZ. What baffles me most, is the nature of the bug. It is the text book case of a high priority bug, new (budget) hardware, which is becoming common place very fast, where Fedora isn't bootable, add to that it is a regression bug. How does a bug with these characteristics not come within the peripheral vision of the maintainers, specially when the reporter is eager to do all kinds of troubleshooting and testing!? Clearly something is wrong with the automation, the question is. how should that be fixed? -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thu, 28 May 2020 21:19:34 -0700, John M. Harris Jr wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1742960 > > > > > > Lately all my bug reports tend to go like this. > > > > > > Why don't you try to reproduce issues with Fedora 31, 32 or Rawhide > > and then reassign the tickets accordingly? > > It's quite possible that Suvayu Ali is one of the many users that cannot > install Fedora 31, because it doesn't work on their hardware. Fedora 30 was > the last release to support i686, so many users are now stuck there forever, > unless they move to another distro entirely. Clearly the ticket is about x86_64, so no, i686 is beyond the scope of this thread. But when talking about i686, I doubt it is "many users". ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On 5/28/20 9:19 PM, John M. Harris Jr wrote: It's quite possible that Suvayu Ali is one of the many users that cannot install Fedora 31, because it doesn't work on their hardware. Fedora 30 was the last release to support i686, so many users are now stuck there forever, unless they move to another distro entirely. If it's a 32-bit issue then it has become irrelevant anyway since that is no longer supported in Fedora. I have a computer mounted on my wall that used to run Fedora. It has a Cyrix Geode processor and a few years ago Fedora was no longer suitable for it. I didn't fuss at Fedora about that, technology moves on. I switched to buildroot instead, which works much better. Please accept that the decision has been made and other major distros are doing the same. Stop bringing it up all the time. If you really have a device that can only do 32-bit, there are still other options. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Wednesday, May 27, 2020 2:30:11 AM MST Michael Schwendt wrote: > On Wed, 27 May 2020 08:18:48 +, Suvayu Ali wrote: > > > > > As of the 26th of May 2020, Fedora 30 has reached its end of life for > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1742960 > > > > Lately all my bug reports tend to go like this. > > > Why don't you try to reproduce issues with Fedora 31, 32 or Rawhide > and then reassign the tickets accordingly? It's quite possible that Suvayu Ali is one of the many users that cannot install Fedora 31, because it doesn't work on their hardware. Fedora 30 was the last release to support i686, so many users are now stuck there forever, unless they move to another distro entirely. -- John M. Harris, Jr. Splentity ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thu, 28 May 2020 18:08:48 +0930, Tim via users wrote: > Perhaps there should be an automated culling of participants. If you > step up the plate to say you'll maintain a package, but don't, *you* > get dumped from bugzilla. Please let's not create a thread of doom. You can't seriously suggest blocking kernel maintainers from bugzilla just because they don't have the manpower to take a look at every ticket and perform meaningful, helpful triaging. Some key components are literally flooded with bug reports. In order to deal with the number of tickets, using scripts is an obvious thing to do. Yet it isn't done in a proper and OS user-friendly way. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thu, May 28, 2020 at 05:01:19PM +0100, Patrick O'Callaghan wrote: > I didn't say to remove the packages, but to mark them as "unmaintained" > (assuming there is such a mechanism). There is a process to orphan packages, but it is a process started by the maintainer. Periodically, you can see on the -devel list that unresponsive maintainers have their packages orphaned. This leads to all sorts of dependency issues. A bunch of java dependencies were orphaned earlier this year, iirc, and it caused many packages to be removed because their dependencies could not be met. Basically, a huge chunk of the java ecosystem in Fedora went away. -- Jonathan Billings ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Lets follow the removing the maintainers if they don't respond to BZ'.s So we remove maintainers, we don't get a replacement maintainer and then after a few times of unmaintained packages, we remove the packages. Repeat until we have no packages except the most basic packages. Everyone seems to believe the maintainers are being paid to answer our questions by someone and/or required to respond to the BZ, they aren't. And there seems to be the believe that it is an honor to be a maintainer and that there are people waiting in line for the job, and they aren't. When you have paid support (read 10k's of paid distro copies) the maintainers always respond, and often the response is "engineering is looking at that" repeated until the enterprise packages goes EOL, or "we aren't going to fix that". Also remember the Distro maintainer is more or less just packaging it up and/or slightly adjusting for fedora and maybe some testing. They rarely own the original package source code, and rarely do they even know enough to do major code changes. I know I debugged and submitted code a fix to a package I like to use that had some code backported incorrectly and must have had only limited testing. Kernel bugs should be duplicated on the newest kernel.org kernel and then details posted to the linux kernel list, that will get it fixed upstream which in 30-60days or so will magically show up in fedora. Much the same thing is true with the packages, it is best to go to the actual package maintainer outside of the distro as they may have actually written the code. i know of at least one of "the engineering is looking at that" and/or "we aren't going to fix" that got fixed because someone I work with went to the upstream maintainer and fixed it at the source, and that got packaged up into the distro. If you fix it upstream you can also make the much simpler request to backport patch from upstream and/or uplift to current upstream the given package. On Thu, May 28, 2020 at 10:26 AM Tim via users wrote: > > Tim: > >> Perhaps there should be an automated culling of participants. If > >> you step up the plate to say you'll maintain a package, but don't, > >> *you* get dumped from bugzilla. > > Patrick O'Callaghan: > > I was about to suggest something similar. Not necessarily dumping > > them from BZ but removing the package's "maintained" status (or > > whatever the terminology is). Clearly if bug reports are not being > > addressed, the package is not being maintained in any meaningful > > sense. > > The trouble with dumping unmaintained packages is that you can remove > packages that actually work for some people (on distros that cull > unmaintained packages). Ignoring faulty ones, for the moment, there's > plenty of abandoned things that still work. Even broken ones may work > for some people. > > I do think it's fair to remove someone who isn't actually contributing. > There's no point in them being there if they don't do anything. > > -- > > uname -rsvp > Linux 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64 > > Boilerplate: All unexpected mail to my mailbox is automatically deleted. > I will only get to see the messages that are posted to the mailing list. > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > 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/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Fri, 2020-05-29 at 00:55 +0930, Tim via users wrote: > Tim: > > > Perhaps there should be an automated culling of participants. If > > > you step up the plate to say you'll maintain a package, but don't, > > > *you* get dumped from bugzilla. > > Patrick O'Callaghan: > > I was about to suggest something similar. Not necessarily dumping > > them from BZ but removing the package's "maintained" status (or > > whatever the terminology is). Clearly if bug reports are not being > > addressed, the package is not being maintained in any meaningful > > sense. > > The trouble with dumping unmaintained packages is that you can remove > packages that actually work for some people (on distros that cull > unmaintained packages). Ignoring faulty ones, for the moment, there's > plenty of abandoned things that still work. Even broken ones may work > for some people. > > I do think it's fair to remove someone who isn't actually contributing. > There's no point in them being there if they don't do anything. I didn't say to remove the packages, but to mark them as "unmaintained" (assuming there is such a mechanism). poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Tim: >> Perhaps there should be an automated culling of participants. If >> you step up the plate to say you'll maintain a package, but don't, >> *you* get dumped from bugzilla. Patrick O'Callaghan: > I was about to suggest something similar. Not necessarily dumping > them from BZ but removing the package's "maintained" status (or > whatever the terminology is). Clearly if bug reports are not being > addressed, the package is not being maintained in any meaningful > sense. The trouble with dumping unmaintained packages is that you can remove packages that actually work for some people (on distros that cull unmaintained packages). Ignoring faulty ones, for the moment, there's plenty of abandoned things that still work. Even broken ones may work for some people. I do think it's fair to remove someone who isn't actually contributing. There's no point in them being there if they don't do anything. -- uname -rsvp Linux 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
2020-05-28 15:00 UTC+02:00, Ralf Corsepius : > Please do yourself a favor and check which packages and which packages > you talking about. As I wrote before, there are obvious patterns, but we > all know the people in charge are not interested. Wouldn't it be simpler if you told us, instead of sending all interested readers go chasing patterns? Andras ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
2020-05-28 13:30 UTC+02:00, Patrick O'Callaghan : > On Thu, 2020-05-28 at 18:08 +0930, Tim via users wrote: [...] >> Perhaps there should be an automated culling of participants. If you >> step up the plate to say you'll maintain a package, but don't, *you* >> get dumped from bugzilla. > > I was about to suggest something similar. Not necessarily dumping them > from BZ but removing the package's "maintained" status (or whatever the > terminology is). Clearly if bug reports are not being addressed, the > package is not being maintained in any meaningful sense. What if half of the reports are addressed, resulting in a lot of happy users? The same for maintainers: what if a maintainer addresses half of the issues he's supposed to? Should (s)he still get dumped? Andras ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On 5/28/20 1:30 PM, Patrick O'Callaghan wrote: On Thu, 2020-05-28 at 18:08 +0930, Tim via users wrote: Perhaps there should be an automated culling of participants. If you step up the plate to say you'll maintain a package, but don't, *you* get dumped from bugzilla. I was about to suggest something similar. Not necessarily dumping them from BZ but removing the package's "maintained" status (or whatever the terminology is). Clearly if bug reports are not being addressed, the package is not being maintained in any meaningful sense. Please do yourself a favor and check which packages and which packages you talking about. As I wrote before, there are obvious patterns, but we all know the people in charge are not interested. Ralf ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thu, 2020-05-28 at 18:08 +0930, Tim via users wrote: > On Thu, 2020-05-28 at 10:00 +0200, Michael Schwendt wrote: > > There have always been components with a large number of bugzilla > > tickets without a response, but Fedora has turned it into a "man > > versus machine" competition. Which is unfortunate. First of all, > > those automated responses come _much_ too late. After months, most > > users have lost patience and have given up. And for the patient > > users, the second time somebody gets an automated response that only > > threatens with closing a ticket _again_, it will be a "WTF?" moment > > and raise motivation to look for a different OS. > > > > Automation is not a bad thing, but there ought to be a clear message > > that tells people about the expectations to get a response on the way > > to a potential fix or _how_ they could contribute. > > I too have had bugs that were ignored over several releases (and the > fault remained). The only activity seemed to have been waiting to see > if the next distro release fixed it. Not even questioning me to try > and find more information to fix things. It seemed like the package > maintainer was not really in a position to debug things. > > Only when I had been able to work out that a particular file was > missing, or some other thing where I could determine the fault, but not > actually do the repair, was anything done about the bug. > > Perhaps there should be an automated culling of participants. If you > step up the plate to say you'll maintain a package, but don't, *you* > get dumped from bugzilla. I was about to suggest something similar. Not necessarily dumping them from BZ but removing the package's "maintained" status (or whatever the terminology is). Clearly if bug reports are not being addressed, the package is not being maintained in any meaningful sense. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thu, 2020-05-28 at 10:00 +0200, Michael Schwendt wrote: > There have always been components with a large number of bugzilla > tickets without a response, but Fedora has turned it into a "man > versus machine" competition. Which is unfortunate. First of all, > those automated responses come _much_ too late. After months, most > users have lost patience and have given up. And for the patient > users, the second time somebody gets an automated response that only > threatens with closing a ticket _again_, it will be a "WTF?" moment > and raise motivation to look for a different OS. > > Automation is not a bad thing, but there ought to be a clear message > that tells people about the expectations to get a response on the way > to a potential fix or _how_ they could contribute. I too have had bugs that were ignored over several releases (and the fault remained). The only activity seemed to have been waiting to see if the next distro release fixed it. Not even questioning me to try and find more information to fix things. It seemed like the package maintainer was not really in a position to debug things. Only when I had been able to work out that a particular file was missing, or some other thing where I could determine the fault, but not actually do the repair, was anything done about the bug. Perhaps there should be an automated culling of participants. If you step up the plate to say you'll maintain a package, but don't, *you* get dumped from bugzilla. -- uname -rsvp Linux 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Thu, 28 May 2020 07:50:16 +, Suvayu Ali wrote: > It took so long, that the bug report became irrelevant. I have since > moved to a different country, with a different job, and don't have > access to the original machine. In fact, as mentioned in the bug, I > could reproduce a similar issue in similar hardware, with Fedora 31. There is more to it. Assuming you would have reassigned the ticket to Fedora 31 in response to the "MASS BUG UPDATE" notification on 2020-03-03, without any clear and concise reply you cannot tell whether you would be testing a potentially fixed kernel or just a random kernel rebase that may or may not fix it. Furthermore, you don't even know whether the reported problem is tracked anywhere where somebody would look at it _eventually_. The ticket status is entirely unclear. "Please test [...] and let us know [...]", but nobody has responded to the feedback. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Wed, 27 May 2020 15:42:39 -0400, Ben Cotton wrote: > On Wed, May 27, 2020 at 3:23 PM Michael Schwendt wrote: > > > > The fundamental problem here is that it has taken a very long time for > > somebody to respond to the bug reporter. There has been no guidance and > > no hint whether anyone "somewhere" would be interested in looking into > > this issue. > > > Exactly. And growing the contributor community is how we can solve that > problem. > How? It seems to be you haven't even taken a brief look at the ticket at all. The bug reporter has contributed more than only dumping a kernel backtrace into bugzilla. The willingness to provide details or to test potential fixes has been demonstrated. And yet nobody has shown any willingness to comment on the actual problem or to point at external place that might be a suitable place where to discuss it and where interested kernel developers could give some guidance on how to proceed. There have always been components with a large number of bugzilla tickets without a response, but Fedora has turned it into a "man versus machine" competition. Which is unfortunate. First of all, those automated responses come _much_ too late. After months, most users have lost patience and have given up. And for the patient users, the second time somebody gets an automated response that only threatens with closing a ticket _again_, it will be a "WTF?" moment and raise motivation to look for a different OS. Automation is not a bad thing, but there ought to be a clear message that tells people about the expectations to get a response on the way to a potential fix or _how_ they could contribute. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
Hi Michael, Ben, On Wed, May 27, 2020 at 7:23 PM Michael Schwendt wrote: > > On Wed, 27 May 2020 12:07:35 -0400, Ben Cotton wrote: > > > On Wed, May 27, 2020 at 4:30 AM Suvayu Ali wrote: > > > > > > Lately all my bug reports tend to go like this. Are others having the > > > same experience? > > > > I understand the frustration. My bugs get closed EOL, too. For what > > it's worth, 3633 bugs were closed EOL for Fedora 30. This is > > considerably lower than Fedora 29 (4958) and Fedora 28 (4681). > > > > The Fedora Join SIG is here to help new contributors get started if > > you're interested: > > https://docs.fedoraproject.org/en-US/fedora-join/index.html > > That process would not have helped with this kernel bugzilla ticket > opened in 2019-08-18. But the response in March 2020 suggested reproducing > the issue with Fedora 31 and reassigning the ticket, if the issue is still > reproducible. That has not been done. > > The fundamental problem here is that it has taken a very long time for > somebody to respond to the bug reporter. There has been no guidance and > no hint whether anyone "somewhere" would be interested in looking into > this issue. It took so long, that the bug report became irrelevant. I have since moved to a different country, with a different job, and don't have access to the original machine. In fact, as mentioned in the bug, I could reproduce a similar issue in similar hardware, with Fedora 31. The old hardware was Ryzen 5 2400G, and the second one was Ryzen 7 PRO 3700U (a mobile CPU with similar design, don't get confused with the 2xxx vs 3xxx naming). No response. Even more importantly, this started as a regression bug that renders a system unbootable; my understanding of Fedora and Linux kernel policy says that's very high severity, and still I saw absolutely no response. Ironically, the bug on 3700U got almost resolved by a very recent Fedora 32 kernel update this month (that's 10 months, and 2 distro upgrades later). Given the apathy, I had not bothered any more to file a bug report specifically for the 3700U. This is not the first time, I had purchased the 2400G within the first month of its release back in Feb-Mar 2018. Understandably there were issues (system unbootable to a desktop), even then, my bug reports did not get a single response, me talking to myself, reporting back with my experiments and attempted workarounds. With the release of a new kernel series, about 2-3 months later, all issues were resolved. In the least, I could have helped test any bleeding edge kernels. I have been using Fedora for over a decade, have contributed to the distribution in many different ways (packaging, testing, etc). This is not a one off issue, I have had bugs open for many other packages, all have faced the same fate. If I can't participate in the community, when I'm competent, and willing, I will regrettably move, despite loving the distro; most likely to Arch. Cheers, -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On 5/27/20 9:42 PM, Ben Cotton wrote: On Wed, May 27, 2020 at 3:23 PM Michael Schwendt wrote: The fundamental problem here is that it has taken a very long time for somebody to respond to the bug reporter. There has been no guidance and no hint whether anyone "somewhere" would be interested in looking into this issue. Exactly. And growing the contributor community is how we can solve that problem. Is this more than a cheap excuse? This problem exists ever since Fedora exists and has never been addressed. I agree with Michael. The fundamental problem is many maintainers not responding in timely manners (when a problem still is acute to the reporter), but maintainers trying to "sit out" problems until garbage collection sweeps them under the carpet. Furthermore, when you have a closer look at which BZs don't get addressed you'll find pretty obvious patterns, for the reasons why they have not been addressed. Ralf ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Wed, May 27, 2020 at 3:23 PM Michael Schwendt wrote: > > The fundamental problem here is that it has taken a very long time for > somebody to respond to the bug reporter. There has been no guidance and > no hint whether anyone "somewhere" would be interested in looking into > this issue. > Exactly. And growing the contributor community is how we can solve that problem. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Wed, 27 May 2020 12:07:35 -0400, Ben Cotton wrote: > On Wed, May 27, 2020 at 4:30 AM Suvayu Ali wrote: > > > > Lately all my bug reports tend to go like this. Are others having the > > same experience? > > I understand the frustration. My bugs get closed EOL, too. For what > it's worth, 3633 bugs were closed EOL for Fedora 30. This is > considerably lower than Fedora 29 (4958) and Fedora 28 (4681). > > The Fedora Join SIG is here to help new contributors get started if > you're interested: > https://docs.fedoraproject.org/en-US/fedora-join/index.html That process would not have helped with this kernel bugzilla ticket opened in 2019-08-18. But the response in March 2020 suggested reproducing the issue with Fedora 31 and reassigning the ticket, if the issue is still reproducible. That has not been done. The fundamental problem here is that it has taken a very long time for somebody to respond to the bug reporter. There has been no guidance and no hint whether anyone "somewhere" would be interested in looking into this issue. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Wed, May 27, 2020 at 4:30 AM Suvayu Ali wrote: > > Lately all my bug reports tend to go like this. Are others having the > same experience? I understand the frustration. My bugs get closed EOL, too. For what it's worth, 3633 bugs were closed EOL for Fedora 30. This is considerably lower than Fedora 29 (4958) and Fedora 28 (4681). The Fedora Join SIG is here to help new contributors get started if you're interested: https://docs.fedoraproject.org/en-US/fedora-join/index.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Wed, 27 May 2020 08:18:48 +, Suvayu Ali wrote: > > As of the 26th of May 2020, Fedora 30 has reached its end of life for > > https://bugzilla.redhat.com/show_bug.cgi?id=1742960 > > Lately all my bug reports tend to go like this. Why don't you try to reproduce issues with Fedora 31, 32 or Rawhide and then reassign the tickets accordingly? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
Re: Fedora 30 EOL
On Tue, May 26, 2020 at 4:23 PM Mohan Boddu wrote: > > As of the 26th of May 2020, Fedora 30 has reached its end of life for https://bugzilla.redhat.com/show_bug.cgi?id=1742960 Lately all my bug reports tend to go like this. Are others having the same experience? I have been using Fedora a long time, and part of the pleasure was I could contribute to making the distro better. Now it seems to have reduced to "wait until it fixes itself", how is that any different from Windows/Mac? It's very disappointing to see the community aspect of Fedora go down this way while the OS has improved by so much compared to when I started using Fedora. -- Suvayu Open source is the future. It sets us free. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org
