3:12 a.m.
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?
3:23 a.m.
No way.
You can add comaintainer for EPEL builds of your packages.
чт, 30 янв. 2020 г. в 12:13, Michael Schwendt <mschwendt(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
3:31 a.m.
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._D...
3:32 a.m.
On Thu, Jan 30, 2020, 10:13 Michael Schwendt <mschwendt(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
7:44 a.m.
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
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.
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
8:15 a.m.
On Thu, Jan 30, 2020 at 2:46 PM Kevin Kofler <kevin.kofler(a)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
>
> 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.
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
4:24 p.m.
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.
4:57 p.m.
On Thu, Jan 30, 2020 at 11:26 PM Michael Schwendt <mschwendt(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
5:33 p.m.
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.
5:42 p.m.
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.
5:54 p.m.
On Fri, Jan 31, 2020, 00:43 Michael Schwendt <mschwendt(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
4:53 a.m.
On Fri, 31 Jan 2020 at 00:56, Fabio Valentini <decathorpe(a)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.
11:10 a.m.
Fabio Valentini <decathorpe(a)gmail.com> writes:
Michael Schwendt <mschwendt(a)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
1:15 p.m.
On Fri, 31 Jan 2020 at 18:11, Robbie Harwood <rharwood(a)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.
1:45 p.m.
Michael Schwendt <mschwendt(a)gmail.com> writes:
On Fri, 31 Jan 2020 at 18:11, Robbie Harwood
<rharwood(a)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
3:58 p.m.
On Fri, 31 Jan 2020 at 20:45, Robbie Harwood <rharwood(a)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._D...
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.
6:35 p.m.
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
7:12 p.m.
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
7:42 p.m.
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.
:-/
3:32 a.m.
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
4:23 a.m.
On Tue, 5 May 2020 at 10:33, Pierre-Yves Chibon <pingou(a)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!
4:31 a.m.
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(a)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
1445
days inactive
1541
days old
21 comments
8 participants
participants (8)
-
Fabio Valentini -
James Cassell -
Jeff Fearn -
Kevin Kofler -
Michael Schwendt -
Pierre-Yves Chibon -
Robbie Harwood -
Vascom