Re: "Gardening" old bugreports
I don't think that wishlist items should be treated in the same way as actual bugs. Even if the original reporter is no longer interested in a wishlist report or is no longer contactable, the feature asked for may still be valid. For KAlarm at least, please exclude wishlist reports from gardening processes. On 19 January 2023 06:17:23 GMT, AnnoyingRains wrote: > Also, note that we can provide exceptions when doing this, like we have > done with Krita, (excluded from both MR and bug report cleanup). If you > would like your project to be excluded, just let us know! > > Thanks > - Kye Potter, KDE Gardening > > On Thu, 19 Jan 2023 at 5:07 pm, Laurent Montel wrote: > > > Hi, > > For pim* it’s ok for me. > > We have a very old bug, but pim* changed a lot. > > Or some apps are dead (blogilo etc.) > > A lot of bug report are duplicated or obsolete. > > > > Thanks for doing it. > > Regards > > > > Le jeudi 19 janvier 2023, 04:04:45 CET Justin a écrit : > > > Hi Nicolas, > > > > > > This has been discussed with Nate Graham directly who has approved this > > > cleanup of Bugzilla including the messaging behind it. > > > > > > I am happy to discuss any concerns that people have around this. I > > > understand Krita requested we exclude them from any gardening and that > > > has been done, however this is the only feedback I have received. > > > > > > The gardening team aims to find out if the bug reports are still > > > relevant by involving the users who reported them in determining if they > > > are still valid. This increases community involvement and helps KDE as > > > there isn't anywhere near enough manpower to review the thousands upon > > > thousands of bugs that haven't been touched in years. > > > > > > The bugs that we are interacting with are ones that have not had any > > > activity for over 2 years. We are simply trying to reinvigorate > > > discussion on those bugs to see if they are still valid. If the user > > > does not reply within the standard 30 day period after a bug is set to > > > NEEDSINFO, it is automatically closed by the Bug Janitor. > > > > > > I am not simply closing bugs, so I do take offense that care is not > > applied. > > > > > > I will halt it until it is approved by more developers. However if it is > > > decided that it isn't wanted then the KDE as a whole will need to entice > > > more people in sorting old bugs individually as it is clearly not a > > > priority right now for the majority. > > > > > > Regards, > > > > > > Justin > > > > > > On 19/1/23 11:05, Nicolas Fella wrote: > > > > Hi, > > > > > > > > can we please put the effort of "gardening" old bugreports on hold > > until > > > > we figured out whether this is actually something we want to do? > > Several > > > > people already expressed concerns about this. > > > > > > > > Improperly applied such mass changes can do more harm than good. We may > > > > close bugreports that are actually still useful just because nobody > > > > replied on then in a relatively short timeframe. > > > > > > > > Properly cleaning up old bugreports is important. However, it requires > > > > some level of care and expertise to judge whether a bugreport is still > > > > useful. Judging by the volume of bugreports that is pinged with the > > same > > > > copy&paste message this care is not applied here. > > > > > > > > At minimum such initiatives should be announced and discussed before > > > > doing them, to allow people to give their input on the proposal. I am > > > > not aware of any such announcement/discussion. > > > > > > > > Cheers > > > > > > > > Nicolas > > > > > > -- > > Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software > > Engineer > > KDAB (France) S.A.S., a KDAB Group company > > Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr > > KDAB - The Qt, C++ and OpenGL Experts > > > > > > -- David Jarvie KAlarm author, KDE developer
Re: "Gardening" old bugreports
Wishlist items are already excluded for all projects. On Thu, 19 Jan 2023, 7:39 pm David Jarvie, wrote: > I don't think that wishlist items should be treated in the same way as > actual bugs. Even if the original reporter is no longer interested in a > wishlist report or is no longer contactable, the feature asked for may > still be valid. > > For KAlarm at least, please exclude wishlist reports from gardening > processes. > > On 19 January 2023 06:17:23 GMT, AnnoyingRains > wrote: >> >> Also, note that we can provide exceptions when doing this, like we have >> done with Krita, (excluded from both MR and bug report cleanup). If you >> would like your project to be excluded, just let us know! >> >> Thanks >> - Kye Potter, KDE Gardening >> >> On Thu, 19 Jan 2023 at 5:07 pm, Laurent Montel wrote: >> >>> Hi, >>> For pim* it’s ok for me. >>> We have a very old bug, but pim* changed a lot. >>> Or some apps are dead (blogilo etc.) >>> A lot of bug report are duplicated or obsolete. >>> >>> Thanks for doing it. >>> Regards >>> >>> Le jeudi 19 janvier 2023, 04:04:45 CET Justin a écrit : >>> > Hi Nicolas, >>> > >>> > This has been discussed with Nate Graham directly who has approved this >>> > cleanup of Bugzilla including the messaging behind it. >>> > >>> > I am happy to discuss any concerns that people have around this. I >>> > understand Krita requested we exclude them from any gardening and that >>> > has been done, however this is the only feedback I have received. >>> > >>> > The gardening team aims to find out if the bug reports are still >>> > relevant by involving the users who reported them in determining if >>> they >>> > are still valid. This increases community involvement and helps KDE as >>> > there isn't anywhere near enough manpower to review the thousands upon >>> > thousands of bugs that haven't been touched in years. >>> > >>> > The bugs that we are interacting with are ones that have not had any >>> > activity for over 2 years. We are simply trying to reinvigorate >>> > discussion on those bugs to see if they are still valid. If the user >>> > does not reply within the standard 30 day period after a bug is set to >>> > NEEDSINFO, it is automatically closed by the Bug Janitor. >>> > >>> > I am not simply closing bugs, so I do take offense that care is not >>> applied. >>> > >>> > I will halt it until it is approved by more developers. However if it >>> is >>> > decided that it isn't wanted then the KDE as a whole will need to >>> entice >>> > more people in sorting old bugs individually as it is clearly not a >>> > priority right now for the majority. >>> > >>> > Regards, >>> > >>> > Justin >>> > >>> > On 19/1/23 11:05, Nicolas Fella wrote: >>> > > Hi, >>> > > >>> > > can we please put the effort of "gardening" old bugreports on hold >>> until >>> > > we figured out whether this is actually something we want to do? >>> Several >>> > > people already expressed concerns about this. >>> > > >>> > > Improperly applied such mass changes can do more harm than good. We >>> may >>> > > close bugreports that are actually still useful just because nobody >>> > > replied on then in a relatively short timeframe. >>> > > >>> > > Properly cleaning up old bugreports is important. However, it >>> requires >>> > > some level of care and expertise to judge whether a bugreport is >>> still >>> > > useful. Judging by the volume of bugreports that is pinged with the >>> same >>> > > copy&paste message this care is not applied here. >>> > > >>> > > At minimum such initiatives should be announced and discussed before >>> > > doing them, to allow people to give their input on the proposal. I am >>> > > not aware of any such announcement/discussion. >>> > > >>> > > Cheers >>> > > >>> > > Nicolas >>> >>> >>> -- >>> Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software >>> Engineer >>> KDAB (France) S.A.S., a KDAB Group company >>> Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr >>> KDAB - The Qt, C++ and OpenGL Experts >>> >>> >>> -- > David Jarvie > KAlarm author, KDE developer >
Re: Registration
On Thu, Jan 19, 2023 at 9:04 AM wrote: > I'm waiting for an answer, mr. sysadmin. If you accuse me of bad conduct, > account for it and explain your accusations. > > -- > I'm using Tutanota - the end-to-end encrypted email service > > > > 17 янв. 2023 г., 20:06 От be...@tuta.io: > > What backend provider is that? And for what reason did it list my email? > > For security reasons I won't be disclosing our backend provider for this information. I can confirm that they do not provide any information regarding why an entry was listed though. > "I've also set the moderation flag on them for this mailing list" - and > what does your moderation flag mean? > > It means your messages will be held for moderator approval prior to being accepted. As other members of the community have noted, the tone of your messages isn't particularly appreciated by others. > "it is very common for VPN providers and services like Tor to be blocked > from registering" - that is a lie. I've registered on many forums through a > VPN and never been blocked. > > Different sites have different policies. > "it is not the first time i've seen conduct like this (have seen far worse > actually)". Excuse me? What "bad conduct" are we talking about here? Point > to just one place in my letters where I attacked anyone personally. > "directed at Sysadmin" - another lie. In order to attack a sysadmin > personally, you at least need to know who that sysadmin is, which I > obviously didn't. > > The tone of your messages is rather abrasive which others in our community have confirmed (see Konstantin's response for one) and also contains insults. So what I see from your side is insinuations and lies (including a couple > of trolls earlier), which truly is a bad conduct. I didn't attack you in > any way, so be so kind to explain this gratuitious aggression. > > Regards, Ben Cooksley KDE Sysadmin > > -- > I'm using Tutanota - the end-to-end encrypted email service > > > > 17 янв. 2023 г., 12:01 От bcooks...@kde.org: > > I have checked the backend provider we use to determine if someone is a > spammer. > The email address of the person trying to register here was listed by that > provider back in November 2022. > > The action of KDE Identity in this instance was therefore correct and > given their conduct I'm not going to be manually overriding it in this > instance. > I've also set the moderation flag on them for this mailing list. > > For the record, due to the amount of abuse that they're utilised for, it > is very common for VPN providers and services like Tor to be blocked from > registering. > > With regards to the conduct of this person, it is not the first time i've > seen conduct like this (have seen far worse actually) directed at Sysadmin > or the services we operate (for those wondering) > > Thanks, > Ben Cooksley > KDE Sysadmin > > On Tue, Jan 17, 2023 at 9:36 PM Konstantin Kharlamov > wrote: > > Indeed, given web sites are usually maintained by system administrators > and that there's also a "sysadmin" KDE mailing list, I have no idea what > are you doing here. > > With that said, I'm not sure you will get any help at all after the amount > of insults you've done. I see someone elsewhere in the discussion even > started to troll you, I don't think that is a good reaction either. > > Anyway, in terms of future advice: please apply Hanlon's Razor, it is most > often correct, i.e. no one attempted to attribute malice to you. People > make mistakes (like the one with the site), which Hanlon's razor describes > as well. > > Also, vast majority of KDE contributors aren't funded (and I'm sure no one > by you specifically), so nobody has obligations to you. > > Try to understand that and try to be calmer the next time you attempt to > collaborate with any project, be it KDE or something else. If anything, > insulting maintainers of a project you're interested in just impacts moral > resources of its maintainers, hence impacts you specifically as a user of > that project, as it may make maintainer procrastinate due to stress the > project just brought thanks to you. > > For example, there's one big project I'm not gonna name for translating > API calls to analogous ones on other systems. It's hard to contribute to > for an outsider, which I experienced twice, I currently have a patch > addressing serious usability problem that no amount of pinging makes to > either merge or at least to review. It's just ignored. That annoys me, but > do I insult them? Of course no, it is an active project (mostly due to paid > developers) which I'm using, so what good would insulting them do? Nothing. > > On Mon, 2023-01-16 at 22:36 +0100, be...@tuta.io wrote: > > Who could I refer to in the developers' mailing list? Hmm, let me ponder > this question, it's so complicated... > > -- > I'm using Tutanota - the end-to-end encrypted email service > > > > 16 янв. 2023 г., 16:24 От nmariu...@gmail.com: > > Hello, > > When you say "Did you design this thing in suc
Re: "Gardening" old bugreports
On Thu, Jan 19, 2023 at 4:05 AM Justin wrote: > The gardening team aims to find out if the bug reports are still > relevant by involving the users who reported them in determining if they > are still valid. FWIW that probably doesn't work nearly as well as one would hope when the user is a developer. I for one just ignore the entire flood of ping comments. I'm 99% certain bugs I have reported have been closed as collateral damage. HS
Re: "Gardening" old bugreports
I'll have a look when I'm back at my PC and see if I can exclude bugs reported by you. On Thu, 19 Jan 2023, 8:57 pm Harald Sitter, wrote: > On Thu, Jan 19, 2023 at 4:05 AM Justin wrote: > > The gardening team aims to find out if the bug reports are still > > relevant by involving the users who reported them in determining if they > > are still valid. > > FWIW that probably doesn't work nearly as well as one would hope when > the user is a developer. I for one just ignore the entire flood of > ping comments. I'm 99% certain bugs I have reported have been closed > as collateral damage. > > HS >
Re: "Gardening" old bugreports
Actually, what if we just ignore reports that come from a *@kde.org email address? On Thu, 19 Jan 2023 at 9:42 pm, Justin Zobel wrote: > I'll have a look when I'm back at my PC and see if I can exclude bugs > reported by you. > > On Thu, 19 Jan 2023, 8:57 pm Harald Sitter, wrote: > >> On Thu, Jan 19, 2023 at 4:05 AM Justin wrote: >> > The gardening team aims to find out if the bug reports are still >> > relevant by involving the users who reported them in determining if they >> > are still valid. >> >> FWIW that probably doesn't work nearly as well as one would hope when >> the user is a developer. I for one just ignore the entire flood of >> ping comments. I'm 99% certain bugs I have reported have been closed >> as collateral damage. >> >> HS >> >
Re: "Gardening" old bugreports
We can do that but not all developers use a KDE email address. On Thu, 19 Jan 2023, 9:15 pm AnnoyingRains, wrote: > Actually, what if we just ignore reports that come from a *@kde.org email > address? > > On Thu, 19 Jan 2023 at 9:42 pm, Justin Zobel > wrote: > >> I'll have a look when I'm back at my PC and see if I can exclude bugs >> reported by you. >> >> On Thu, 19 Jan 2023, 8:57 pm Harald Sitter, wrote: >> >>> On Thu, Jan 19, 2023 at 4:05 AM Justin wrote: >>> > The gardening team aims to find out if the bug reports are still >>> > relevant by involving the users who reported them in determining if >>> they >>> > are still valid. >>> >>> FWIW that probably doesn't work nearly as well as one would hope when >>> the user is a developer. I for one just ignore the entire flood of >>> ping comments. I'm 99% certain bugs I have reported have been closed >>> as collateral damage. >>> >>> HS >>> >>
Re: "Gardening" old bugreports
Hi, Am 19.01.23 um 04:04 schrieb Justin: Hi Nicolas, This has been discussed with Nate Graham directly who has approved this cleanup of Bugzilla including the messaging behind it. KDE consists of more than Nate tough. We discuss and "review" things in the open. I am happy to discuss any concerns that people have around this. I understand Krita requested we exclude them from any gardening and that has been done, however this is the only feedback I have received. The gardening team aims to find out if the bug reports are still relevant by involving the users who reported them in determining if they are still valid. This increases community involvement and helps KDE as there isn't anywhere near enough manpower to review the thousands upon thousands of bugs that haven't been touched in years. Anecdotally many people don't like such automated changes being done to their bugreports that don't actually engage with the content of the report. The bugs that we are interacting with are ones that have not had any activity for over 2 years. We are simply trying to reinvigorate discussion on those bugs to see if they are still valid. If the user does not reply within the standard 30 day period after a bug is set to NEEDSINFO, it is automatically closed by the Bug Janitor. I am not simply closing bugs, so I do take offense that care is not applied. Properly "triaging" old reports requires at least some level of understanding of the project, codebase etc. I'm afraid there is no simple solution to that and rule-based approaches aren't good enough. Even taking things like CONFIRMED status or wishlist priority into account assumes that these have actually been consistently applied. I will halt it until it is approved by more developers. However if it is decided that it isn't wanted then the KDE as a whole will need to entice more people in sorting old bugs individually as it is clearly not a priority right now for the majority. Regards, Justin Don't get me wrong, I do appreciate the initiative of cleaning up bugs. But we do need to handle this with a lot of care to avoid it backfiring. Cheers Nico On 19/1/23 11:05, Nicolas Fella wrote: Hi, can we please put the effort of "gardening" old bugreports on hold until we figured out whether this is actually something we want to do? Several people already expressed concerns about this. Improperly applied such mass changes can do more harm than good. We may close bugreports that are actually still useful just because nobody replied on then in a relatively short timeframe. Properly cleaning up old bugreports is important. However, it requires some level of care and expertise to judge whether a bugreport is still useful. Judging by the volume of bugreports that is pinged with the same copy&paste message this care is not applied here. At minimum such initiatives should be announced and discussed before doing them, to allow people to give their input on the proposal. I am not aware of any such announcement/discussion. Cheers Nicolas
Re: "Gardening" old bugreports
In the regard then it falls to developers with the understanding of the codebase to triage these. However it's clear due to the age of these bugs that most developers don't have time or aren't prioritising these reports. This is why I've volunteered time to try get engagement happening with community (the bug reporters) to help confirm these issues still exist and if they do, try and encourage evolvement from the project maintainers. Regards, Justin On Thu, 19 Jan 2023, 9:56 pm Nicolas Fella, wrote: > Hi, > > Am 19.01.23 um 04:04 schrieb Justin: > > Hi Nicolas, > > > > This has been discussed with Nate Graham directly who has approved > > this cleanup of Bugzilla including the messaging behind it. > > KDE consists of more than Nate tough. We discuss and "review" things in > the open. > > > > > I am happy to discuss any concerns that people have around this. I > > understand Krita requested we exclude them from any gardening and that > > has been done, however this is the only feedback I have received. > > > > The gardening team aims to find out if the bug reports are still > > relevant by involving the users who reported them in determining if > > they are still valid. This increases community involvement and helps > > KDE as there isn't anywhere near enough manpower to review the > > thousands upon thousands of bugs that haven't been touched in years. > > Anecdotally many people don't like such automated changes being done to > their bugreports that don't actually engage with the content of the report. > > > > > The bugs that we are interacting with are ones that have not had any > > activity for over 2 years. We are simply trying to reinvigorate > > discussion on those bugs to see if they are still valid. If the user > > does not reply within the standard 30 day period after a bug is set to > > NEEDSINFO, it is automatically closed by the Bug Janitor. > > > > I am not simply closing bugs, so I do take offense that care is not > > applied. > > Properly "triaging" old reports requires at least some level of > understanding of the project, codebase etc. I'm afraid there is no > simple solution to that and rule-based approaches aren't good enough. > Even taking things like CONFIRMED status or wishlist priority into > account assumes that these have actually been consistently applied. > > > > > I will halt it until it is approved by more developers. However if it > > is decided that it isn't wanted then the KDE as a whole will need to > > entice more people in sorting old bugs individually as it is clearly > > not a priority right now for the majority. > > > > Regards, > > > > Justin > > > Don't get me wrong, I do appreciate the initiative of cleaning up bugs. > But we do need to handle this with a lot of care to avoid it backfiring. > > Cheers > > Nico > > > > On 19/1/23 11:05, Nicolas Fella wrote: > >> Hi, > >> > >> can we please put the effort of "gardening" old bugreports on hold until > >> we figured out whether this is actually something we want to do? Several > >> people already expressed concerns about this. > >> > >> Improperly applied such mass changes can do more harm than good. We may > >> close bugreports that are actually still useful just because nobody > >> replied on then in a relatively short timeframe. > >> > >> Properly cleaning up old bugreports is important. However, it requires > >> some level of care and expertise to judge whether a bugreport is still > >> useful. Judging by the volume of bugreports that is pinged with the same > >> copy&paste message this care is not applied here. > >> > >> At minimum such initiatives should be announced and discussed before > >> doing them, to allow people to give their input on the proposal. I am > >> not aware of any such announcement/discussion. > >> > >> Cheers > >> > >> Nicolas > >> >
Re: "Gardening" old bugreports
Involvement not evolvement. On Thu, 19 Jan 2023, 10:06 pm Justin Zobel, wrote: > In the regard then it falls to developers with the understanding of the > codebase to triage these. > > However it's clear due to the age of these bugs that most developers don't > have time or aren't prioritising these reports. > > This is why I've volunteered time to try get engagement happening with > community (the bug reporters) to help confirm these issues still exist and > if they do, try and encourage evolvement from the project maintainers. > > Regards, > > Justin > > On Thu, 19 Jan 2023, 9:56 pm Nicolas Fella, wrote: > >> Hi, >> >> Am 19.01.23 um 04:04 schrieb Justin: >> > Hi Nicolas, >> > >> > This has been discussed with Nate Graham directly who has approved >> > this cleanup of Bugzilla including the messaging behind it. >> >> KDE consists of more than Nate tough. We discuss and "review" things in >> the open. >> >> > >> > I am happy to discuss any concerns that people have around this. I >> > understand Krita requested we exclude them from any gardening and that >> > has been done, however this is the only feedback I have received. >> > >> > The gardening team aims to find out if the bug reports are still >> > relevant by involving the users who reported them in determining if >> > they are still valid. This increases community involvement and helps >> > KDE as there isn't anywhere near enough manpower to review the >> > thousands upon thousands of bugs that haven't been touched in years. >> >> Anecdotally many people don't like such automated changes being done to >> their bugreports that don't actually engage with the content of the >> report. >> >> > >> > The bugs that we are interacting with are ones that have not had any >> > activity for over 2 years. We are simply trying to reinvigorate >> > discussion on those bugs to see if they are still valid. If the user >> > does not reply within the standard 30 day period after a bug is set to >> > NEEDSINFO, it is automatically closed by the Bug Janitor. >> > >> > I am not simply closing bugs, so I do take offense that care is not >> > applied. >> >> Properly "triaging" old reports requires at least some level of >> understanding of the project, codebase etc. I'm afraid there is no >> simple solution to that and rule-based approaches aren't good enough. >> Even taking things like CONFIRMED status or wishlist priority into >> account assumes that these have actually been consistently applied. >> >> > >> > I will halt it until it is approved by more developers. However if it >> > is decided that it isn't wanted then the KDE as a whole will need to >> > entice more people in sorting old bugs individually as it is clearly >> > not a priority right now for the majority. >> > >> > Regards, >> > >> > Justin >> > >> Don't get me wrong, I do appreciate the initiative of cleaning up bugs. >> But we do need to handle this with a lot of care to avoid it backfiring. >> >> Cheers >> >> Nico >> >> >> > On 19/1/23 11:05, Nicolas Fella wrote: >> >> Hi, >> >> >> >> can we please put the effort of "gardening" old bugreports on hold >> until >> >> we figured out whether this is actually something we want to do? >> Several >> >> people already expressed concerns about this. >> >> >> >> Improperly applied such mass changes can do more harm than good. We may >> >> close bugreports that are actually still useful just because nobody >> >> replied on then in a relatively short timeframe. >> >> >> >> Properly cleaning up old bugreports is important. However, it requires >> >> some level of care and expertise to judge whether a bugreport is still >> >> useful. Judging by the volume of bugreports that is pinged with the >> same >> >> copy&paste message this care is not applied here. >> >> >> >> At minimum such initiatives should be announced and discussed before >> >> doing them, to allow people to give their input on the proposal. I am >> >> not aware of any such announcement/discussion. >> >> >> >> Cheers >> >> >> >> Nicolas >> >> >> >
Re: Frameworks master is Qt6 now
Am 18.01.23 um 23:58 schrieb Nicolas Fella: Hi, the master branch of frameworks repositories now required Qt6 to build. Maintenance of KF5 continues in the "kf5" branch. Those using kdesrc-build make sure your kdesrc-builrc contains "branch-group kf5-qt5", then it will switch to the correct branch automatically. Those building manually please adjust your workflow accordingly. Any merge requests for frameworks should target Qt6/master (unless they are not applicable there). If the change should be backported to KF5 cherry-pick it to the kf5 branch after merging. Note that for the time being the kf5 branch has to stay compatible with Qt6. This is required to keep the currently existing Qt6 builds working. This does *not* mean that master is now open for any kind of breaking change. We will announce more on this soon. Assuming no major issues with our tooling crop up soon we will proceed with the following changes: - Bump the KF_VERSION in master to 5.240.0. At some point we will release one or more beta versions, which will have 5.250.0 etc as version number. This is to follow the practice of .80/.90 version numbers, but slightly adjusted to account for 255 being the technical upper limit. - Drop build system code to build with Qt5 - Rename library/target names to KF6 - Drop deprecated API. To ensure compatibility with existing Qt6 builds this will initially be done only for API that was deprecated before 5.100 since that is what the current Qt6 CI enforces. Eventually we of course want to drop everything deprecated, but that requires porting consumers of it first. I expect this to happen over the next few days. I will announce once this is done and master is open for more invasive changes. Cheers Nicolas
Re: "Gardening" old bugreports
Hello folks, I did approve this initiative and I do think there's value to it, but of course we can definitely have this discussion in the open and tweak its parameters, or end it if we think it's destroying more value than it's creating. I totally agree with Nicolas that in an ideal world, all bug triaging would be done on a bug-by-bug-basis, and this is what I personally do with products I'm familiar with and have some technical knowledge about. But I also can't blame anyone else who doesn't do this, because manual bug triaging is a tedious, laborious, time-consuming, energy-draining task. It's hard enough for new bugs, and for old bugs which were poorly-handled in the past, lack key information, or are full of angry users, it can be even more unpleasant. In my experience mentoring volunteer bug triagers over the past 5 years, few stick around for manual bug triage longer than about 3 months. It's not fun and it feels like work. It's hard enough even to get maintainers to do it consistently, for the same completely justifiable reasons. I have tremendous respect for those who grit their teeth and do it anyway. But it's currently not enough to handle the volume of bug reports we get daily, or reduce the backlog of old un-handled bugs. This causes Bugzilla's signal-to-noise ratio to worsen over time. The automatic bug triage initiative emerged to try to address that. If our consensus ends up being to terminate it, I'd like it to be because more folks are stepping up to make manual bug triage a part of their daily routine--and not just for new bugs, but for old ones too. And on a consistent basis, not just once or twice. The more human labor we get consistently working on the problem, the less drive there will be for machines to do it. Here's our documentation on how to do it: https://community.kde.org/index.php?title=Guidelines_and_HOWTOs/Bug_triaging If that doesn't happen, I think we need to consider other options for bug management, such as doing it automatically or hiring more people to do it manually. Let me know your thoughts! Nate
Re: "Gardening" old bugreports
On 1/19/23 02:35, Nicolas Fella wrote:> Properly cleaning up old bugreports is important. However, it requires some level of care and expertise to judge whether a bugreport is still useful. Judging by the volume of bugreports that is pinged with the same copy&paste message this care is not applied here. For projects like kwin it's unrealistic to go through all bug reports. Just for the record, there are currently almost 1.3k open bug reports filed for kwin. Going through old bug reports is not fun! After triaging about 20 bug reports, I already feel exhausted. It's a time and energy consuming process that kills future motivation to do bug triaging again. Now scale that to 1000 bug reports! I have no doubt that there are old bug reports that are actually still valid and useful. But, from my personal experience, the ratio of such good bug reports to "noise" is small. > Improperly applied such mass changes can do more harm than good. We may > close bugreports that are actually still useful just because nobody > replied on then in a relatively short timeframe. IMHO it makes sense to poke old bug reports (say 1 year old or so) My two cents, Vlad
Re: "Gardening" old bugreports
Hi, Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas Fella: > Am 19.01.23 um 04:04 schrieb Justin: > > The gardening team aims to find out if the bug reports are still > > relevant by involving the users who reported them in determining if > > they are still valid. This increases community involvement and helps > > KDE as there isn't anywhere near enough manpower to review the > > thousands upon thousands of bugs that haven't been touched in years. > > Anecdotally many people don't like such automated changes being done to > their bugreports that don't actually engage with the content of the report. Well, anecdotally you will mostly get feedback from people who don't like it. Unless something is exceptionally great, few people will take the time to speak out in favor of something that is already happening. > > The bugs that we are interacting with are ones that have not had any > > activity for over 2 years. We are simply trying to reinvigorate > > discussion on those bugs to see if they are still valid. If the user > > does not reply within the standard 30 day period after a bug is set to > > NEEDSINFO, it is automatically closed by the Bug Janitor. > > > > I am not simply closing bugs, so I do take offense that care is not > > applied. > > Properly "triaging" old reports requires at least some level of > understanding of the project, codebase etc. I'm afraid there is no > simple solution to that and rule-based approaches aren't good enough. > Even taking things like CONFIRMED status or wishlist priority into > account assumes that these have actually been consistently applied. As a maintainer on a small project, I'm quite happy to get an occasional nudge on old reports. Yes, I do occasionally go over old reports to see if they are still valid, but having somebody else doing this methodically makes sure I don't gloss over some bug that could be closed or fixed. Having this done by someone else without too much internal knowledge is an absolute plus in my opinion. After all, if you want to clean up your attic, you try to find a helper who does not have the same emotional attachment as yourself. > > I will halt it until it is approved by more developers. However if it > > is decided that it isn't wanted then the KDE as a whole will need to > > entice more people in sorting old bugs individually as it is clearly > > not a priority right now for the majority. Speaking for KPhotoAlbum, I really appreciate the bugzilla gardening. Thank you for doing it! Cheers, Johannes
[ANNOUNCE] CMake 3.25.2 available for download
We are pleased to announce that CMake 3.25.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! Changes made since CMake 3.25.1: Andrey Vostrikov (1): CheckSymbolExists: Restore newline at end of test source Brad King (14): Utilities/Release: Use explicit digest for Win7-compatible signature Help: Clarify SYSTEM property default for imported targets gitlab-ci: replace '$os' tags with '$os-x86_64' on 3.25 release branch gitlab-ci: drop unnecessary linux kernel version tag on 3.25 release branch ccmake: Restore compilation with AIX curses.h ASM_MASM: Populate MSVC debug information format abstraction table VS: Do not enable ASM_MASM debug information unless requested gitlab-ci: update macOS jobs to use Xcode 14.2 Tests: Fix CTest.UpdateGIT under repo-local defaultBranch config try_run: Avoid crash in keyword-dispatched signature when cross-compiling Restore implicit include directory extraction for adaptive relative paths IntelLLVM: Avoid unnecessary -Qstd=c++11 flag on Windows Help: Restore cmake-buildsystem(7) header-only library example CMake 3.25.2 Craig Scott (3): FetchContent: Don't pass SYSTEM through to sub-build Help: Clarify and update SYSTEM-related docs Code comments: Fix trivial typos Marc Chevrier (2): Help: Add version information for SYSTEM option of add_subdirectory Help: string(JSON): avoid duplicate labels Michael Hirsch (2): IntelLLVM: Avoid finding not-yet-supported icpx on Windows Help: Clarify compiler id distinction between Intel Classic and IntelLLVM Robert Maynard (2): CUDA: Add support for cuda_std_20 for nvcc 12.0+ FindCUDAToolkit: Handle CUDA::nvToolsExt not existing leha-bot (2): zlib: Fix typo in mangling the crc32() function FindBoost: Add Boost 1.81 support
