I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages. I don't want to be the new default owner of EPEL bugzilla tickets. Where may I be able to stop this mess?
No way. You can add comaintainer for EPEL builds of your packages.
чт, 30 янв. 2020 г. в 12:13, Michael Schwendt mschwendt@gmail.com:
I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages. I don't want to be the new default owner of EPEL bugzilla tickets. Where may I be able to stop this mess?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
On Thu, 30 Jan 2020 12:23:01 +0300, Vascom wrote:
No way. You can add comaintainer for EPEL builds of your packages.
That can't be right.
Who has made me the "owner" of claws-mail in EPEL? And why?
https://fedoraproject.org/wiki/EPEL/FAQ#I_maintain_a_package_in_Fedora._Do_I...
On Thu, Jan 30, 2020, 10:13 Michael Schwendt mschwendt@gmail.com wrote:
I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages. I don't want to be the new default owner of EPEL bugzilla tickets. Where may I be able to stop this mess?
Until this functionality is merged into pagure's dist-git plugin, there is a way, but it's a bit convoluted.
You can set an override for Fedora / EPEL default assignees in yaml files stored here, like this one for maven:
https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/maven
1. fork the repo 2. modify files for packages 3. set default assignee for EPEL to someone else 4. open a Pull Request 5. wait
Just look at some of the other packages for the correct formatting. I'm on mobile right now so it's a bit hard for me to look for a fitting example just now.
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
Fabio Valentini wrote:
Until this functionality is merged into pagure's dist-git plugin, there is a way, but it's a bit convoluted.
You can set an override for Fedora / EPEL default assignees in yaml files stored here, like this one for maven:
https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/maven
- fork the repo
- modify files for packages
- set default assignee for EPEL to someone else
- open a Pull Request
- wait
Just look at some of the other packages for the correct formatting. I'm on mobile right now so it's a bit hard for me to look for a fitting example just now.
And we have to do that for every single package we maintain? That is not reasonable. It is Fedora policy that we cannot be forced to care about EPEL. The software needs to actually implement that policy.
Kevin Kofler
On Thu, Jan 30, 2020 at 2:46 PM Kevin Kofler kevin.kofler@chello.at wrote:
Fabio Valentini wrote:
Until this functionality is merged into pagure's dist-git plugin, there is a way, but it's a bit convoluted.
You can set an override for Fedora / EPEL default assignees in yaml files stored here, like this one for maven:
https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/maven
- fork the repo
- modify files for packages
- set default assignee for EPEL to someone else
- open a Pull Request
- wait
Just look at some of the other packages for the correct formatting. I'm on mobile right now so it's a bit hard for me to look for a fitting example just now.
And we have to do that for every single package we maintain? That is not reasonable. It is Fedora policy that we cannot be forced to care about EPEL. The software needs to actually implement that policy.
Apparently, yes. At least with the current approach, it should be easily scriptable with a few dozen LOC.
You could file an RFE for pagure (-dist-git?) (since those assignee overrides are currently getting implemented there) to make EPEL branches always have an "orphan" override by default, unless somebody actively changes that value.
Fabio
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
On Thu, 30 Jan 2020 14:44:50 +0100, Kevin Kofler wrote:
Fabio Valentini wrote:
Until this functionality is merged into pagure's dist-git plugin, there is a way, but it's a bit convoluted.
And it's too obscure. Instead, I just retired the two EPEL branches.
And we have to do that for every single package we maintain? That is not reasonable. It is Fedora policy that we cannot be forced to care about EPEL. The software needs to actually implement that policy.
With pkgdb I could see who maintains which "branches" and which branches exist. With this new web UI, I don't find where I could take a look at who maintains which branch. For some packages I see socalled "members", a "main admin", an "admin", people with "commit" access, but without any idea who maintains which branches.
All this would not even interest me at all, but almost a week ago someone from Red Hat Security decided it would be a good idea to assign to me (without asking first) ancient EPEL tickets, which are almost five years (!) old. Apparently, no proper tracking of those tickets has been done for a very long time. It is entirely wrong and unexpected to assign those EPEL tickets to me only because something under the hood knows only a default assignee or such.
On Thu, Jan 30, 2020 at 11:26 PM Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 30 Jan 2020 14:44:50 +0100, Kevin Kofler wrote:
Fabio Valentini wrote:
Until this functionality is merged into pagure's dist-git plugin, there is a way, but it's a bit convoluted.
And it's too obscure. Instead, I just retired the two EPEL branches.
Did you at least check if the packages were used by something else? ...
And as I said, a new self-service UI for setting bugzilla overrides for Fedora branches vs. EPEL branches is being worked on for src.fedoraproject.org.
And we have to do that for every single package we maintain? That is not reasonable. It is Fedora policy that we cannot be forced to care about EPEL. The software needs to actually implement that policy.
With pkgdb I could see who maintains which "branches" and which branches exist. With this new web UI, I don't find where I could take a look at who maintains which branch. For some packages I see socalled "members", a "main admin", an "admin", people with "commit" access, but without any idea who maintains which branches.
That's because per-branch maintainership is no longer "supported", as mentioned on recent other threads. It seems the "support" in PkgDB was also a "lie", because BugZilla doesn't even support default assignees per-branch.
All this would not even interest me at all, but almost a week ago someone from Red Hat Security decided it would be a good idea to assign to me (without asking first) ancient EPEL tickets, which are almost five years (!) old. Apparently, no proper tracking of those tickets has been done for a very long time. It is entirely wrong and unexpected to assign those EPEL tickets to me only because something under the hood knows only a default assignee or such.
For new tickets, I'd understand this. But for old tickets to get reassigned to you - I agree that that's weird. I wonder who the previous assignee was, and why it was decided to reassign now, after 5 years?
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
On 31/1/20 08:57, Fabio Valentini wrote:
With pkgdb I could see who maintains which "branches" and which branches exist. With this new web UI, I don't find where I could take a look at who maintains which branch. For some packages I see socalled "members", a "main admin", an "admin", people with "commit" access, but without any idea who maintains which branches.
That's because per-branch maintainership is no longer "supported", as mentioned on recent other threads. It seems the "support" in PkgDB was also a "lie", because BugZilla doesn't even support default assignees per-branch.
While this is true in general, you need to take in to account that EPEL is a separate product in Bugzilla and therefore it is possible to have different defaults for EPEL bugs than for Fedora bugs.
I believe this is what pkgdb supported, separate EPEL and Fedora defaults, not a more general per branch default.
Cheers, Jeff.
On Thu, 30 Jan 2020 23:57:03 +0100, Fabio Valentini wrote:
Did you at least check if the packages were used by something else? ...
No, and that doesn't interest me at all. I am not doing EPEL packaging, and I consider it inacceptable that somebody assigns five years old EPEL tickets to me and expects me to handle the tickets as well as the packages.
That's because per-branch maintainership is no longer "supported", as mentioned on recent other threads.
That doesn't sound good.
Is it anything final that has been communicated on devel-announce list in a clear way? Or is it buried beneath hundreds to thousands of posts on devel list?
It seems the "support" in PkgDB was also a "lie", because BugZilla doesn't even support default assignees per-branch.
It just worked, and when somebody opened a ticket about an EPEL package, the EPEL-specific maintainer became the assignee _by default_. Whether bugzilla knows a separate "default assignee" is beyond my interest, unless somebody or some script reassigns tickets to me which are not of my concern.
On Fri, Jan 31, 2020, 00:43 Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 30 Jan 2020 23:57:03 +0100, Fabio Valentini wrote:
Did you at least check if the packages were used by something else? ...
No, and that doesn't interest me at all. I am not doing EPEL packaging, and I consider it inacceptable that somebody assigns five years old EPEL tickets to me and expects me to handle the tickets as well as the packages.
That's because per-branch maintainership is no longer "supported", as mentioned on recent other threads.
That doesn't sound good.
Is it anything final that has been communicated on devel-announce list in a clear way? Or is it buried beneath hundreds to thousands of posts on devel list?
It seems the "support" in PkgDB was also a "lie", because BugZilla doesn't even support default assignees per-branch.
It just worked, and when somebody opened a ticket about an EPEL package, the EPEL-specific maintainer became the assignee _by default_. Whether bugzilla knows a separate "default assignee" is beyond my interest, unless somebody or some script reassigns tickets to me which are not of my concern.
Did you actually read what I wrote? I said "per branch maintainership" is not supported, and never really was. But I explicitly wrote that you're able to make a destinction between bug assignees for fedora and EPEL versions of your package ...
It's just that there's no nice UI for setting this up since PkgDB went away. Until it's integrated into pagure-dist-git, you can do it by submitting changes to fedora-scm-requests via PR.
So what you want to achieve (not get bugs for EPEL component assigned to you) still works today and will keep working, with UI for it on the way ...
Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
On Fri, 31 Jan 2020 at 00:56, Fabio Valentini decathorpe@gmail.com wrote:
It seems the "support" in PkgDB was also a "lie", because BugZilla doesn't even support default assignees per-branch.
It just worked, and when somebody opened a ticket about an EPEL package, the EPEL-specific maintainer became the assignee _by default_. Whether bugzilla knows a separate "default assignee" is beyond my interest, unless somebody or some script reassigns tickets to me which are not of my concern.
Did you actually read what I wrote? I said "per branch maintainership" is not supported, and never really was. But I explicitly wrote that you're able to make a destinction between bug assignees for fedora and EPEL versions of your package ...
You are talking in riddles then. Either bugzilla can handle different assignees for EPEL and Fedora, or it can't. Even prior to pkgdb, we had a list in cvs with different "package owners" for EPEL and Fedora, and e.g. for rpmfusion I created a script that synced the data to bugzilla, so we could create new components in bugzillla and update them, too, simply by running a script periodically. It just worked. EPEL package had different assignees than Fedora packages. And orphans would be assigned to orphan owner appropriately.
So what you want to achieve (not get bugs for EPEL component assigned to you) still works today and will keep working, with UI for it on the way ...
As in the original email that starts this thread, I never signed up as a maintainer for EPEL packages and don't want to become an assignee (and/or "default assignee") for them either. In this mysterious pagure webui I cannot even see what I'm assigned to and what fellow packagers are assigned to. All I see for "claws-mail" is that there is only a single "member", but I cannot see any data that would give hints about what's up with the EPEL packages.
Fabio Valentini decathorpe@gmail.com writes:
Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 30 Jan 2020 14:44:50 +0100, Kevin Kofler wrote:
Fabio Valentini wrote:
All this would not even interest me at all, but almost a week ago someone from Red Hat Security decided it would be a good idea to assign to me (without asking first) ancient EPEL tickets, which are almost five years (!) old. Apparently, no proper tracking of those tickets has been done for a very long time. It is entirely wrong and unexpected to assign those EPEL tickets to me only because something under the hood knows only a default assignee or such.
For new tickets, I'd understand this. But for old tickets to get reassigned to you - I agree that that's weird.
I wonder who the previous assignee was, and why it was decided to reassign now, after 5 years?
Andreas Bierfert (awjb), who was recently declared non-responsive. So: the assignee of the bug is not around to determine whether it can be fixed.
I could have also needinfo(Michael) (and in hindsight I probably should have), but based on their reaction, I don't think they would have been any happier with that.
My view is that there's an open security bug, so it's reasonable to want to know whether it's going to be fixed. The assignee clearly isn't going to answer it. Someone responsible for another branch of the package should be able to check trivially - and is indeed the best person to ask, since they're the most locally knowledgeable.
In communication with Michael, I did explain that if no one was responsible for these branches, they should retire the branches. Michael's view in that discussion seemed to be that the problem was one I had created, and therefore one I should fix. (Michael can retire the branches while I, an unrelated contributor without ProvenPackager, cannot.)
Thanks, --Robbie
On Fri, 31 Jan 2020 at 18:11, Robbie Harwood rharwood@redhat.com wrote:
I could have also needinfo(Michael) (and in hindsight I probably should have), but based on their reaction, I don't think they would have been any happier with that.
I would have preferred private email over assigning multiple tickets to me and causing bugzilla spam for all the ticket changes including (!) multiple needinfo inquiries.
Andreas Bierfert (awjb), who was recently declared non-responsive.
That could have been mentioned. Is that when some process transferred EPEL packages to me without prior asking?
My view is that there's an open security bug, so it's reasonable to want to know whether it's going to be fixed.
You consider it reasonable to look into ancient security issues after almost five years? The related tracking bugs did serve no purpose for almost five years?
Someone responsible for another branch of the package should be able to check trivially - and is indeed the best person to ask, since they're the most locally knowledgeable.
As I've pointed out in private email, with proper reporting and tracking of those CVEs, the CVE ids would be mentioned in the spec %changelog of the Fedora package, where typically a much newer version is packaged. If none of those security issues has been reported for Fedora, it should be safe to assume that the Fedora packages have not been deemed vulnerable.
In communication with Michael, I did explain that if no one was responsible for these branches, they should retire the branches. Michael's view in that discussion seemed to be that the problem was one I had created, and therefore one I should fix. (Michael can retire the branches while I, an unrelated contributor without ProvenPackager, cannot.)
As pointed out, I don't keep an eye on EPEL. I'm completely surprised that all of a sudden I am expected to look into EPEL packaging matters. I still don't understand why I have become the assignee of EPEL tickets and possibly EPEL packages, too, when I never asked for that.
Michael Schwendt mschwendt@gmail.com writes:
On Fri, 31 Jan 2020 at 18:11, Robbie Harwood rharwood@redhat.com wrote:
I could have also needinfo(Michael) (and in hindsight I probably should have), but based on their reaction, I don't think they would have been any happier with that.
I would have preferred private email over assigning multiple tickets to me and causing bugzilla spam for all the ticket changes including (!) multiple needinfo inquiries.
You received a total of between 4 and 8 emails depending on how bugzilla batched them. My apologies for the extra 3-7.
Andreas Bierfert (awjb), who was recently declared non-responsive.
That could have been mentioned. Is that when some process transferred EPEL packages to me without prior asking?
I did mention it. My words were that "the maintainer is no longer active in Fedora, and you're the default assignee for the package".
Your response, by the way, was: "Would you mind becoming familiar with the Fedora Project a bit?".
My view is that there's an open security bug, so it's reasonable to want to know whether it's going to be fixed.
You consider it reasonable to look into ancient security issues after almost five years? The related tracking bugs did serve no purpose for almost five years?
Yes? This shouldn't come as a surprise to you. The whole process of security bugs, CVEs, and the like exists to get them *fixed*. If they are in fact not, you might not care about EPEL, but EPEL doesn't want to ship vulnerable software any more than you do.
Someone responsible for another branch of the package should be able to check trivially - and is indeed the best person to ask, since they're the most locally knowledgeable.
As I've pointed out in private email, with proper reporting and tracking of those CVEs, the CVE ids would be mentioned in the spec %changelog of the Fedora package, where typically a much newer version is packaged. If none of those security issues has been reported for Fedora, it should be safe to assume that the Fedora packages have not been deemed vulnerable.
You are repeatedly ignoring that I'm not concerned about the Fedora package. Please stop. You are subject mater expert for the project. No one is better suited than you to answer the question of whether a given version is affected or not.
In communication with Michael, I did explain that if no one was responsible for these branches, they should retire the branches. Michael's view in that discussion seemed to be that the problem was one I had created, and therefore one I should fix. (Michael can retire the branches while I, an unrelated contributor without ProvenPackager, cannot.)
As pointed out, I don't keep an eye on EPEL. I'm completely surprised that all of a sudden I am expected to look into EPEL packaging matters. I still don't understand why I have become the assignee of EPEL tickets and possibly EPEL packages, too, when I never asked for that.
I mentioned that in my emails, and people have repeatedly explained it to you here too. I *also* mentioned in my email that if no one is responsible for them to your knowledge, the proper thing to do was to remove the branches, and provided you information on how to do so.
This isn't a silo. We're supposed to be working together, and helping each other. Your responses of refusing to even consider answering questions about EPEL, replete condescension, and refusal to actually read what I (and others) have been saying continues to make this difficult. Please stop.
Thanks, --Robbie
On Fri, 31 Jan 2020 at 20:45, Robbie Harwood rharwood@redhat.com wrote:
You received a total of between 4 and 8 emails depending on how bugzilla batched them. My apologies for the extra 3-7.
More than eight because of needinfo notifications, "assigned" and "Cc" changes and tracker ticket changes.
Andreas Bierfert (awjb), who was recently declared non-responsive.
That could have been mentioned. Is that when some process transferred EPEL packages to me without prior asking?
I did mention it. My words were that "the maintainer is no longer active in Fedora, and you're the default assignee for the package".
Whenever the non-responsive maintainer procedure was complete, what happened next? The unmaintained EPEL packages ought to have been orphaned or retired properly, and existing bugzilla components reassigned to orphan owner. All within EPEL and without forcefully assigning five years old tickets to a Fedora packager.
Your response, by the way, was: "Would you mind becoming familiar with the Fedora Project a bit?".
EPEL and the Fedora package collection are two separate projects with different maintainers. It's not that the Fedora packages must be anything like "upstream" for the EPEL packages.
Once more, I am not the EPEL maintainer of that package. And I've pointed you at the EPEL FAQ: https://fedoraproject.org/wiki/EPEL/FAQ#I_maintain_a_package_in_Fedora._Do_I...
When you learned that the EPEL maintainer of that package is no longer available, what made you think that you could simply assign the tickets to the Fedora maintainer?
My view is that there's an open security bug, so it's reasonable to want to know whether it's going to be fixed.
You consider it reasonable to look into ancient security issues after almost five years? The related tracking bugs did serve no purpose for almost five years?
Yes? This shouldn't come as a surprise to you. The whole process of security bugs, CVEs, and the like exists to get them *fixed*. If they are in fact not, you might not care about EPEL, but EPEL doesn't want to ship vulnerable software any more than you do.
What do you refuse to understand? I am _not_ the EPEL maintainer of this package. I don't do EPEL packaging. What maintenance procedures are in place for EPEL to handle cases like that without forcefully assigning tickets and/or packages to a Fedora package maintainer?
You are repeatedly ignoring that I'm not concerned about the Fedora package. Please stop.
You've assigned EPEL tickets to a Fedora packager. Can't be so hard to understand that. I've told you about the difference in private email.
You are subject mater expert for the project. No one is better suited than you to answer the question of whether a given version is affected or not.
Have these CVEs been reported about the Fedora package, too, five years ago? Then look up the tracker tickets and the Fedora specific tickets, and the CVE numbers will appear in the package %changelog because of packaging guidelines. Also, have the security issues been reported to upstream or only EPEL?
As pointed out, I don't keep an eye on EPEL. I'm completely surprised that all of a sudden I am expected to look into EPEL packaging matters. I still don't understand why I have become the assignee of EPEL tickets and possibly EPEL packages, too, when I never asked for that.
I mentioned that in my emails, and people have repeatedly explained it to you here too.
Not yet. I've never signed up as the maintainer for EPEL packages.
I *also* mentioned in my email that if no one is responsible for them to your knowledge, the proper thing to do was to remove the branches, and provided you information on how to do so.
Why me? Why did the EPEL package collection contain unmaintained packages? Is no cleanup done for EPEL to properly orphan/retire such packages? Why would you ask a Fedora packager to do it rather than somebody from the EPEL project? Nothing in bugzilla gives a hint that I would be able to do it for EPEL. It was just out of coincidence that I could touch the EPEL packages due to Provenpackager access. Again, I am not an EPEL packager!
This isn't a silo. We're supposed to be working together, and helping each other. Your responses of refusing to even consider answering questions about EPEL, replete condescension, and refusal to actually read what I (and others) have been saying continues to make this difficult. Please stop.
This incident turns into a growingly unpleasant experience for me. I've asked you to clean up the mess in bugzilla and reassign the EPEL packages properly, because I am not responsible for those packages. You've not done that. I've had to do it myself. Team work doesn't mean that you assign tickets to me, which have been neglected/ignored for almost five years. This isn't a hot-potato-dropping contest.
This incident turns into a growingly unpleasant experience for me. I've asked you to clean up the mess in bugzilla and reassign the EPEL packages properly, because I am not responsible for those packages. You've not done that. I've had to do it myself. Team work doesn't mean that you assign tickets to me, which have been neglected/ignored for almost five years. This isn't a hot-potato-dropping contest.
Can this stop, please?
Again somebody has used a script to assign bugzilla EPEL tickets to me again, although I am not responsible for the EPEL packages and have never been responsible for them.
I feel offended.
Whoever is behind this, *please* stop!
Example: https://bugzilla.redhat.com/show_bug.cgi?id=1293581
On Mon, May 4, 2020, at 7:35 PM, Michael Schwendt wrote:
This incident turns into a growingly unpleasant experience for me. I've asked you to clean up the mess in bugzilla and reassign the EPEL packages properly, because I am not responsible for those packages. You've not done that. I've had to do it myself. Team work doesn't mean that you assign tickets to me, which have been neglected/ignored for almost five years. This isn't a hot-potato-dropping contest.
Can this stop, please?
Again somebody has used a script to assign bugzilla EPEL tickets to me again, although I am not responsible for the EPEL packages and have never been responsible for them.
I feel offended.
Whoever is behind this, *please* stop!
Example: https://bugzilla.redhat.com/show_bug.cgi?id=1293581
Looks like some automation, not attributed to a person:
Fedora Admin user for bugzilla script actions 2020-05-04 17:04:23 UTC Assignee extras-orphan bugs.michael
I'm sure someone knows...
V/r James Cassell
On Mon, 04 May 2020 20:12:58 -0400, James Cassell wrote:
Can this stop, please?
Again somebody has used a script to assign bugzilla EPEL tickets to me again, although I am not responsible for the EPEL packages and have never been responsible for them.
I feel offended.
Whoever is behind this, *please* stop!
Example: https://bugzilla.redhat.com/show_bug.cgi?id=1293581
Looks like some automation, not attributed to a person:
Fedora Admin user for bugzilla script actions 2020-05-04 17:04:23 UTC Assignee extras-orphan bugs.michael
I'm sure someone knows...
Automation since when? The ticket is five years old! It was assigned to orphan owner since end of January. Who decided to start a script after such a long time?
If this cannot be stopped, perhaps it's time to orphan or retire the package. I've never signed up as EPEL maintainer. Not even retiring the EPEL packages four months has fixed this mess.
:-/
On Tue, May 05, 2020 at 02:42:27AM +0200, Michael Schwendt wrote:
On Mon, 04 May 2020 20:12:58 -0400, James Cassell wrote:
Can this stop, please?
Again somebody has used a script to assign bugzilla EPEL tickets to me again, although I am not responsible for the EPEL packages and have never been responsible for them.
I feel offended.
Whoever is behind this, *please* stop!
Example: https://bugzilla.redhat.com/show_bug.cgi?id=1293581
Looks like some automation, not attributed to a person:
Fedora Admin user for bugzilla script actions 2020-05-04 17:04:23 UTC Assignee extras-orphan bugs.michael
I'm sure someone knows...
Automation since when? The ticket is five years old! It was assigned to orphan owner since end of January. Who decided to start a script after such a long time?
The scripts syncing information from dist-git to bugzilla have been broken for a long time (less than 5 years though) and we've picked them up, fixed and clean them so they work again. This has been announced here and on devel-announce over the past few months (including an email from yesterday about the move of the bugzilla overrides to dist-git itself).
So after looking at the bug above (the only package I could find in this thread), I went to: https://src.fedoraproject.org/rpms/claws-mail clicked "Edit" on the left hand side column and changed the bugzilla assignee in EPEL to `orphan`. At the next run of the script, the EPEL tickets will be re-assigned to orphan.
Now I ran into this thread a little bit by chance while checking my emails. If you have such issue in the future you may want to actually report it, ie: open a ticket on https://pagure.io/fedora-infrastructure/issues so we can either fix the bug if there is one or tell explain how the situation can be adjusted.
Pierre
On Tue, 5 May 2020 at 10:33, Pierre-Yves Chibon pingou@pingoured.fr wrote:
The scripts syncing information from dist-git to bugzilla have been broken for a long time (less than 5 years though) and we've picked them up, fixed and clean them so they work again. This has been announced here and on devel-announce over the past few months (including an email from yesterday about the move of the bugzilla overrides to dist-git itself).
So after looking at the bug above (the only package I could find in this thread), I went to: https://src.fedoraproject.org/rpms/claws-mail clicked "Edit" on the left hand side column and changed the bugzilla assignee in EPEL to `orphan`. At the next run of the script, the EPEL tickets will be re-assigned to orphan.
Now I ran into this thread a little bit by chance while checking my emails. If you have such issue in the future you may want to actually report it, ie: open a ticket on https://pagure.io/fedora-infrastructure/issues so we can either fix the bug if there is one or tell explain how the situation can be adjusted.
None of that explains why and when I've been assigned to EPEL packages. This is a thread from January.
It's the same with all other packages. The web page you refer to now explicitly claims that somebody is a "Bugzilla Assignee" for EPEL even if a package isn't available in the EPEL dist and despite a person not being active within the EPEL project at all.
While it is good to know that assigning to "orphan" may do something (I had only tried extras-orphan which is the alias that is used in bugzilla, but it was rejected), the information shown on the web page would be misleading and would show that also for packages that don't exist in EPEL. Also, the claws-mail EPEL package branches have been retired in January due to this thread, and nevertheless somewhere I was made the bugzilla assignee again since then. No idea where and when. Hence this thread from January!
On Tue, May 05, 2020 at 11:23:59AM +0200, Michael Schwendt wrote:
On Tue, 5 May 2020 at 10:33, Pierre-Yves Chibon pingou@pingoured.fr wrote:
The scripts syncing information from dist-git to bugzilla have been broken for a long time (less than 5 years though) and we've picked them up, fixed and clean them so they work again. This has been announced here and on devel-announce over the past few months (including an email from yesterday about the move of the bugzilla overrides to dist-git itself).
So after looking at the bug above (the only package I could find in this thread), I went to: https://src.fedoraproject.org/rpms/claws-mail clicked "Edit" on the left hand side column and changed the bugzilla assignee in EPEL to `orphan`. At the next run of the script, the EPEL tickets will be re-assigned to orphan.
Now I ran into this thread a little bit by chance while checking my emails. If you have such issue in the future you may want to actually report it, ie: open a ticket on https://pagure.io/fedora-infrastructure/issues so we can either fix the bug if there is one or tell explain how the situation can be adjusted.
None of that explains why and when I've been assigned to EPEL packages. This is a thread from January.
It's the same with all other packages. The web page you refer to now explicitly claims that somebody is a "Bugzilla Assignee" for EPEL even if a package isn't available in the EPEL dist
That is correct and we'll need to adjust this in the future.
Pierre
devel@lists.stg.fedoraproject.org