Packagers with no corresponding valid bugzilla accounts

[Pierre-Yves Chibon]

Good Morning Everyone,

If you are a packagers or are watching tickets on dist-git (ie: asked to be
cc'ed on tickets on bugzilla for a given package), you must have a valid
bugzilla account associated with the email address you have set in FAS.

There are currently 66 users and groups who do not satisfy this requirement.
This has a direct impact as the script syncing from dist-git to bugzilla the
information about the default assignee and the CC list updates components in
bugzilla in a single request to reduce the load on the server.
So if someone in the CC list does not have a valid bugzilla account, the
entire request will fail to update both the CC list and the default assignee.

Accounts in this state may at some point be removed from packages/cc, so it's
important to correct your account soon!

So, if your name is listed here, please take a minute and create a bugzilla
for the email you have associated with your FAS account:

aarondmarasco
adsllc
affix
ajeetdsouza
alen
amitshah
andreyma
avesh
bpereto
@certbot-sig
csomh
darkdragon001
dcantrel
digimer
dmsimard
doug1
edwintorok
etingof
fepitre
gnikandrov
@graphics-sig
ignotusp
itsbill
jefferson2z
jkratoch
jkreuzer
karsten
kir
klausdevwalker
labbott
lamm
luismartingil
marcdeop
mathstuf
mbartos
mhabrnal
mildew
mmahut
moisesguimaraes
mzidek
nguzman
njohnston
omejzlik
pgibson
portante
proski
rbtr
robled
romal
rpitonak
rspanton
sakalosj
squallbayu
sspreitz
sturivnyi
svahl
tnorth
trasher
tstclair
usercont
vbatts
vicodan
vpolasek
@weldr-sig
yuwata
zmc


If you really to have two distinct email addresses, we keep a mapping of FAS
emails to bugzilla account in [1], which you can update via a pull-request if
you wish to use this.


Thanks for your help,
Pierre


[1]
https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps...

_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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/[e-mail]...

[Jan Kratochvil]

On Sat, 13 Jun 2020 22:10:36 +0200, Pierre-Yves Chibon wrote:
>  jkratoch 
This account is set as "inactive" in FAS. Couldn't you regenerate this list
with inactive accounts excluded?

I would like to remove this old account but FAS admin interface cannot do
that, I can only set it as "inactive".

I am using active account "jankratochvil" instead. In the past I was told it
is easier for Fedora admins to create a new account than to rename my old
account.


Jan

[Pierre-Yves Chibon]

On Sun, Jun 14, 2020 at 08:10:11AM +0200, Jan Kratochvil wrote:
>  On Sat, 13 Jun 2020 22:10:36 +0200, Pierre-Yves Chibon wrote:
>  > jkratoch
>  
>  This account is set as "inactive" in FAS. Couldn't you regenerate this
> list
>  with inactive accounts excluded?
>  
>  I would like to remove this old account but FAS admin interface cannot do
>  that, I can only set it as "inactive".
>  
>  I am using active account "jankratochvil" instead. In the past I was told it
>  is easier for Fedora admins to create a new account than to rename my old
>  account. 
So the source of information used is:
https://src.fedoraproject.org/extras/pagure_bz.json which still indicates that
jkratoch is to be CC'ed for the readline package

If you remove it from there, the question will be solved :)


Pierre

[Felix Schwarz]

Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon:
>  bpereto 
Benjamin was a previous maintainer of borgbackup. After the Python 3.9 rebuild
I noticed that a new ticket was still assigned to him [1]. If I understood
your email correctly this is because there is no corresponding bugzilla account?

Any idea how to fix this? There was a non-responsive maintainer process a
while ago and I did not hear from him ever since.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1838161#c1
[2] https://pagure.io/fesco/issue/2242

>  @certbot-sig 
What can we do here? I'm a member of the sig but I don't know if it has an
email address.

Felix

[Pierre-Yves Chibon]

On Sun, Jun 14, 2020 at 07:09:57PM +0200, Felix Schwarz wrote:
>  
>  Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon:
>  > bpereto
>  
>  Benjamin was a previous maintainer of borgbackup. After the Python 3.9 rebuild
>  I noticed that a new ticket was still assigned to him [1]. If I understood
>  your email correctly this is because there is no corresponding bugzilla account?
>  
>  Any idea how to fix this? There was a non-responsive maintainer process a
>  while ago and I did not hear from him ever since.
>  
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1838161#c1
>  [2] https://pagure.io/fesco/issue/2242 
I've just checked the logs of the sync script and that is correct. Benjamin's
lack of valid bugzilla account lead to a failure in the sync script to update
borgbackup.

Since Benjamin is considered MIA, I will remove his account from the watchers of
borgbackup and that should fix the sync.

>  > @certbot-sig
>  
>  What can we do here? I'm a member of the sig but I don't know if it has an
>  email address. 
Each group has normally a mailing list associated with them in FAS, this is the
email that is synced to bugzilla (which is why we recommend the mailing list be
private as it will be CC'ed to bugzilla reports, including private ones).
So in this case, it looks like no one created the bugzilla account for the
mailing list linked to the group.


Pierre

[Christopher]

Why aren't the packager accounts linked to their FAS account alias?
FASid(a)fedoraproject.org ? I've been annoyed by FAS-linked services trying
to use my forwarding address for my account id rather than my FAS user id.
My forwarding address is subject to change, but the FAS email alias is
static.

On Sun, Jun 14, 2020, 15:03 Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

>  On Sun, Jun 14, 2020 at 07:09:57PM +0200, Felix Schwarz wrote:
>  >
>  > Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon:
>  > > bpereto
>  >
>  > Benjamin was a previous maintainer of borgbackup. After the Python 3.9
>  rebuild
>  > I noticed that a new ticket was still assigned to him [1]. If I
>  understood
>  > your email correctly this is because there is no corresponding bugzilla
>  account?
>  >
>  > Any idea how to fix this? There was a non-responsive maintainer process a
>  > while ago and I did not hear from him ever since.
>  >
>  > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1838161#c1
>  > [2] https://pagure.io/fesco/issue/2242
>
>  I've just checked the logs of the sync script and that is correct.
>  Benjamin's
>  lack of valid bugzilla account lead to a failure in the sync script to
>  update
>  borgbackup.
>
>  Since Benjamin is considered MIA, I will remove his account from the
>  watchers of
>  borgbackup and that should fix the sync.
>
>  > > @certbot-sig
>  >
>  > What can we do here? I'm a member of the sig but I don't know if it has
>  an
>  > email address.
>
>  Each group has normally a mailing list associated with them in FAS, this
>  is the
>  email that is synced to bugzilla (which is why we recommend the mailing
>  list be
>  private as it will be CC'ed to bugzilla reports, including private ones).
>  So in this case, it looks like no one created the bugzilla account for the
>  mailing list linked to the group.
>
>
>  Pierre
>  _______________________________________________
>  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/[e-mail]
>

[Pierre-Yves Chibon]

On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
>     Why aren't the packager accounts linked to their FAS account
> alias?
>     [1]FASid(a)fedoraproject.org ? I've been annoyed by FAS-linked services
>     trying to use my forwarding address for my account id rather than my FAS
>     user id. My forwarding address is subject to change, but the FAS email
>     alias is static. 
Because they are two different systems and you do not need an account in one to
have an account in the other?
We do not create account on bugzilla for the alias @fp.o automatically (and I
think it's a good thing).


Pierre

[Christopher]

On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
>  >    Why aren't the packager accounts linked to their FAS account alias?
>  >    [1]FASid(a)fedoraproject.org ? I've been annoyed by FAS-linked services
>  >    trying to use my forwarding address for my account id rather than my FAS
>  >    user id. My forwarding address is subject to change, but the FAS email
>  >    alias is static.
>
>  Because they are two different systems and you do not need an account in one to
>  have an account in the other?
>  We do not create account on bugzilla for the alias @fp.o automatically (and I
>  think it's a good thing). 
The original post says "If you are a packager... you must have a
bugzilla account...".
But now, you are saying that they are separate and you do not need one
when you have the other.

These two statements are in conflict. Either the bugzilla account is
required for packagers, in which case my suggestion to use the
packager's FAS email alias should suffice (in theory, at least), or it
isn't, in which case, your original post that "...packagers...must
have a bugzilla account..." is incorrect.

You said that the required bugzilla account must be "...associated
with the email address you have set in FAS." All I'm suggesting is
that this is unnecessary if they are packagers, since all packagers
already have a FAS email alias that can be used for this requirement.

[Jonathan Wakely]

On 16/06/20 17:15 -0400, Christopher wrote:
> On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
> >
> > On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
> > >    Why aren't the packager accounts linked to their FAS account alias?
> > >    [1]FASid(a)fedoraproject.org ? I've been annoyed by FAS-linked services
> > >    trying to use my forwarding address for my account id rather than my FAS
> > >    user id. My forwarding address is subject to change, but the FAS email
> > >    alias is static.
> >
> > Because they are two different systems and you do not need an account in one to
> > have an account in the other?
> > We do not create account on bugzilla for the alias @fp.o automatically (and I
> > think it's a good thing).
>
> The original post says "If you are a packager... you must have a
> bugzilla account...".
> But now, you are saying that they are separate and you do not need one
> when you have the other.
>
> These two statements are in conflict. Either the bugzilla account is
> required for packagers, in which case my suggestion to use the
> packager's FAS email alias should suffice (in theory, at least), or it
> isn't, in which case, your original post that "...packagers...must
> have a bugzilla account..." is incorrect.
>
> You said that the required bugzilla account must be "...associated
> with the email address you have set in FAS." All I'm suggesting is
> that this is unnecessary if they are packagers, since all packagers
> already have a FAS email alias that can be used for this requirement. 
I already have a bugzilla.redhat.com account, I don't want another one
for my fedoraproject.org address.

The two systems are separate, and don't need to use the same identity.

[Pierre-Yves Chibon]

On Tue, Jun 16, 2020 at 05:15:17PM -0400, Christopher wrote:
>  On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
>  >
>  > On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
>  > >    Why aren't the packager accounts linked to their FAS account alias?
>  > >    [1]FASid(a)fedoraproject.org ? I've been annoyed by FAS-linked services
>  > >    trying to use my forwarding address for my account id rather than my FAS
>  > >    user id. My forwarding address is subject to change, but the FAS email
>  > >    alias is static.
>  >
>  > Because they are two different systems and you do not need an account in one to
>  > have an account in the other?
>  > We do not create account on bugzilla for the alias @fp.o automatically (and I
>  > think it's a good thing).
>  
>  The original post says "If you are a packager... you must have a
>  bugzilla account...".
>  But now, you are saying that they are separate and you do not need one
>  when you have the other.
>  
>  These two statements are in conflict.  
No they don't, you don't need a FAS account to have a bugzilla account and you
don't need a bugzilla account to have a FAS account.
That being said, if you become a member of the packager group in FAS, you must
have a bugzilla account, which is something that is documented in the process to
join the packager group.
Looking at: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
amusingly it even recommends that the bugzilla account be created before the FAS
one :)


Pierre

[Kevin Fenzi]

On Wed, Jun 17, 2020 at 09:37:42AM +0200, Pierre-Yves Chibon wrote:
>  On Tue, Jun 16, 2020 at 05:15:17PM -0400, Christopher wrote:
>  > On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;
> wrote:
>  > >
>  > > On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
>  > > >    Why aren't the packager accounts linked to their FAS account
> alias?
>  > > >    [1]FASid(a)fedoraproject.org ? I've been annoyed by FAS-linked
> services
>  > > >    trying to use my forwarding address for my account id rather than my
> FAS
>  > > >    user id. My forwarding address is subject to change, but the FAS email
>  > > >    alias is static.
>  > >
>  > > Because they are two different systems and you do not need an account in one
> to
>  > > have an account in the other?
>  > > We do not create account on bugzilla for the alias @fp.o automatically (and I
>  > > think it's a good thing).
>  > 
>  > The original post says "If you are a packager... you must have a
>  > bugzilla account...".
>  > But now, you are saying that they are separate and you do not need one
>  > when you have the other.
>  > 
>  > These two statements are in conflict. 
>  
>  No they don't, you don't need a FAS account to have a bugzilla account and you
>  don't need a bugzilla account to have a FAS account.
>  That being said, if you become a member of the packager group in FAS, you must
>  have a bugzilla account, which is something that is documented in the process to
>  join the packager group.
>  Looking at: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>  amusingly it even recommends that the bugzilla account be created before the FAS
>  one :) 
There's also another case: if you are watching a package (which
means you want to get CC'ed on bugs) you need to also have a bugzilla
account. In this case you also may not have a @fedoraproject.org alias
at all, so if we used that in bugzilla it wouldn't work for those users. 

The new account system we are hoping to move to later in the year I
think will have a dedicated entry for bugzilla account, so you can put
what you prefer in it. (I'm not 100% sure that will be/is implemented,
but it was asked for). 

kevin

[Alexander Ploumistos]

I remember that some time ago we were told not to use the
@fedoraproject.org in bugzilla, can't recall why exactly. Has this
changed?

[Kevin Fenzi]

On Wed, Jun 17, 2020 at 07:52:16PM +0200, Alexander Ploumistos wrote:
>  I remember that some time ago we were told not to use the
>  @fedoraproject.org in bugzilla, can't recall why exactly. Has this
>  changed? 
Nothing has changed there.

You can make a <your-fas-id&gt;(a)fedoraproject.org account, but without an
override on the fedora side it will not be assigned or cc'ed on bugs and
won't get added to the groups that fedora packages and qa folks get
added to. (So you can't set flags, etc)

You can override it on our side (as mentioned upthread with the place
and file to submit a PR against). Then your @fedoraproject.org will be
used for bugzilla and everything else where fas provides an email
address. 

Does that make sense?

kevin

[Alexander Ploumistos]

On Thu, Jun 18, 2020 at 12:08 AM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Wed, Jun 17, 2020 at 07:52:16PM +0200, Alexander Ploumistos wrote:
>  > I remember that some time ago we were told not to use the
>  > @fedoraproject.org in bugzilla, can't recall why exactly. Has this
>  > changed?
>
>  Nothing has changed there.
>
>  You can make a <your-fas-id&gt;(a)fedoraproject.org account, but without an
>  override on the fedora side it will not be assigned or cc'ed on bugs and
>  won't get added to the groups that fedora packages and qa folks get
>  added to. (So you can't set flags, etc)
>
>  You can override it on our side (as mentioned upthread with the place
>  and file to submit a PR against). Then your @fedoraproject.org will be
>  used for bugzilla and everything else where fas provides an email
>  address.
>
>  Does that make sense? 
It does.
In the meantime I managed to dig up that old thread - it was an
exchange between you and Christopher on June 1, 2016.

[Pierre-Yves Chibon]

On Sat, Jun 13, 2020 at 10:10:36PM +0200, Pierre-Yves Chibon wrote:
>  Good Morning Everyone,
>
>  If you are a packagers or are watching tickets on dist-git (ie: asked to be
>  cc'ed on tickets on bugzilla for a given package), you must have a valid
>  bugzilla account associated with the email address you have set in FAS.
>
>  There are currently 66 users and groups who do not satisfy this requirement.
>  This has a direct impact as the script syncing from dist-git to bugzilla the
>  information about the default assignee and the CC list updates components in
>  bugzilla in a single request to reduce the load on the server.
>  So if someone in the CC list does not have a valid bugzilla account, the
>  entire request will fail to update both the CC list and the default assignee.
>
>  Accounts in this state may at some point be removed from packages/cc, so it's
>  important to correct your account soon!
>
>  So, if your name is listed here, please take a minute and create a bugzilla
>  for the email you have associated with your FAS account: 
Good Morning Everyone,

Here is an updated list:

aarondmarasco
adsllc
affix
ajeetdsouza
alen
amitshah
andreyma
avesh
@certbot-sig
csomh
darkdragon001
dcantrel
digimer
dmsimard
doug1
edwintorok
etingof
fepitre
gnikandrov
@graphics-sig
ignotusp
itsbill
jefferson2z
jkreuzer
karsten
kir
klausdevwalker
luismartingil
marcdeop
mathstuf
mbartos
mhabrnal
mildew
mmahut
moisesguimaraes
nguzman
njohnston
omejzlik
pgibson
portante
proski
rbtr
robled
romal
rpitonak
rspanton
sakalosj
squallbayu
sspreitz
sturivnyi
svahl
tnorth
trasher
tstclair
usercont
vbatts
vicodan
vpolasek
@weldr-sig
yshestakov
yuwata
zmc


I have sent direct email to the email of each account on this list.

Please do try to fix this soon!


Pierre

>  If you really to have two distinct email addresses, we keep a mapping
> of FAS
>  emails to bugzilla account in [1], which you can update via a pull-request if
>  you wish to use this.
>
>
>  Thanks for your help,
>  Pierre
>
>
>  [1]
>
> https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps...

_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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/[e-mail]...

[Felix Schwarz]

Am 25.06.20 um 14:55 schrieb Pierre-Yves Chibon:
>  Here is an updated list:
>  
>  @certbot-sig
>  
>  Please do try to fix this soon! 
I'd love to but unfortunately I'm only a user for the certbot sig and even
though I think I'm probably the de-facto maintainer of the certbot stack now I
was not really successful in getting responses from other sig members (trying
for ~6 months now). Also I only learned about the sig mailing lists via this
thread here (but I'm not subscribed there and I don't know how to fix that).

Is there a "non-functional sig" process?

Felix

[Kevin Fenzi]

On Thu, Jun 25, 2020 at 03:56:42PM +0200, Felix Schwarz wrote:
>  
>  Am 25.06.20 um 14:55 schrieb Pierre-Yves Chibon:
>  > Here is an updated list:
>  > 
>  > @certbot-sig
>  > 
>  > Please do try to fix this soon!
>  
>  I'd love to but unfortunately I'm only a user for the certbot sig and even
>  though I think I'm probably the de-facto maintainer of the certbot stack now I
>  was not really successful in getting responses from other sig members (trying
>  for ~6 months now). Also I only learned about the sig mailing lists via this
>  thread here (but I'm not subscribed there and I don't know how to fix that).
>  
>  Is there a "non-functional sig" process? 
File an infra ticket and we will get you access to the list at least...

kevin

[Pierre-Yves Chibon]

On Thu, Jun 25, 2020 at 02:55:50PM +0200, Pierre-Yves Chibon wrote:
>  On Sat, Jun 13, 2020 at 10:10:36PM +0200, Pierre-Yves Chibon wrote:
>  > Good Morning Everyone,
>  >
>  > If you are a packagers or are watching tickets on dist-git (ie: asked to be
>  > cc'ed on tickets on bugzilla for a given package), you must have a valid
>  > bugzilla account associated with the email address you have set in FAS.
>  >
>  > There are currently 66 users and groups who do not satisfy this requirement.
>  > This has a direct impact as the script syncing from dist-git to bugzilla the
>  > information about the default assignee and the CC list updates components in
>  > bugzilla in a single request to reduce the load on the server.
>  > So if someone in the CC list does not have a valid bugzilla account, the
>  > entire request will fail to update both the CC list and the default assignee.
>  >
>  > Accounts in this state may at some point be removed from packages/cc, so it's
>  > important to correct your account soon!
>  >
>  > So, if your name is listed here, please take a minute and create a bugzilla
>  > for the email you have associated with your FAS account:
>   
Good Morning Everyone,

The list is slowly going down, we have now 38 accounts that are still
problematic, they have all received several personal emails over the last few
weeks and none but one reacted.
I will likely start to ping FESCo about them starting next week.

Here is the updated list:
affix
alen
amitshah
andreyma
avesh
dmsimard
etingof
gnikandrov
@graphics-sig
ignotusp
itsbill
jefferson2z
kir
luismartingil
marcdeop
mbartos
mhabrnal
mildew
mmahut
nguzman
pgibson
robled
romal
rpitonak
rspanton
sakalosj
squallbayu
sspreitz
sturivnyi
svahl
tnorth
tstclair
usercont
vbatts
vicodan
vpolasek
@weldr-sig
yuwata

Thanks,

Pierre

_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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/[e-mail]...

[Mattia Verga]

Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
>  Good Morning Everyone,
>
>  The list is slowly going down, we have now 38 accounts that are still
>  problematic, they have all received several personal emails over the last few
>  weeks and none but one reacted.
>  I will likely start to ping FESCo about them starting next week.
>  ... 
 From a quick look to that list, there are some users that have no 
package assigned... I wonder if the unresponsive maintainer process 
implies the user to be removed from the packager group when their 
packages get orphaned and the user has no more any package associated to 
their account.

Here it is the list of packagers without any associated packages:
alen
gnikandrov
itsbill
jefferson2z
kir
pgibson
squallbayu
sturivnyi
yuwata

[Pierre-Yves Chibon]

On Tue, Jul 07, 2020 at 08:17:00AM +0000, Mattia Verga wrote:
>  Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
>  >
>  > Good Morning Everyone,
>  >
>  > The list is slowly going down, we have now 38 accounts that are still
>  > problematic, they have all received several personal emails over the last few
>  > weeks and none but one reacted.
>  > I will likely start to ping FESCo about them starting next week.
>  > ...
>  
>   From a quick look to that list, there are some users that have no 
>  package assigned... I wonder if the unresponsive maintainer process 
>  implies the user to be removed from the packager group when their 
>  packages get orphaned and the user has no more any package associated to 
>  their account. 
The source of info is: https://src.fedoraproject.org/extras/pagure_bz.json
which includes people that are packagers as well as people who are watching the
packages (ie who asked to be included in the CC list on bugzilla).

>  Here it is the list of packagers without any associated packages:
>  alen 
Watching firefox:
http://src.fedoraproject.org/api/0/rpms/firefox/watchers

>  gnikandrov 
Watching setup:
https://src.fedoraproject.org/api/0/rpms/setup/watchers

>  itsbill 
Watching ratpoison:
https://src.fedoraproject.org/api/0/rpms/ratpoison/watchers

>  jefferson2z 
Watching godot:
https://src.fedoraproject.org/api/0/rpms/godot/watchers

>  kir 
Watching criu:
https://src.fedoraproject.org/api/0/rpms/criu/watchers

>  pgibson 
Watching pam:
https://src.fedoraproject.org/api/0/rpms/pam/watchers

>  squallbayu 
Watching gnome-control-center:
https://src.fedoraproject.org/api/0/rpms/gnome-control-center/watchers
and gnome-desktop3
https://src.fedoraproject.org/api/0/rpms/gnome-desktop3/watchers

>  sturivnyi 
Watching cpio:
https://src.fedoraproject.org/api/0/rpms/cpio/watchers

>  yuwata 
Watching dracut, eigen3 and systemd
https://src.fedoraproject.org/api/0/rpms/dracut/watchers
https://src.fedoraproject.org/api/0/rpms/eigen3/watchers
https://src.fedoraproject.org/api/0/rpms/systemd/watchers
 
 
Pierre

[Pierre-Yves Chibon]

On Tue, Jul 07, 2020 at 10:30:02AM +0200, Pierre-Yves Chibon wrote:
>  On Tue, Jul 07, 2020 at 08:17:00AM +0000, Mattia Verga wrote:
>  > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
>  > >
>  > > Good Morning Everyone,
>  > >
>  > > The list is slowly going down, we have now 38 accounts that are still
>  > > problematic, they have all received several personal emails over the last few
>  > > weeks and none but one reacted.
>  > > I will likely start to ping FESCo about them starting next week.
>  > > ...
>  > 
>  >  From a quick look to that list, there are some users that have no 
>  > package assigned... I wonder if the unresponsive maintainer process 
>  > implies the user to be removed from the packager group when their 
>  > packages get orphaned and the user has no more any package associated to 
>  > their account.
>  
>  The source of info is: https://src.fedoraproject.org/extras/pagure_bz.json
>  which includes people that are packagers as well as people who are watching the
>  packages (ie who asked to be included in the CC list on bugzilla). 
So after this, I took a little time to write a script that reports who
maintains/watches what on dist-git (that will be synced to bugzilla).

The script is available at:
https://pagure.io/releng/blob/master/f/scripts/who_maintains_what.py

Here is the list for the users and groups affected:
@graphics-sig is watching rpms/xorg-x11-drv-ati
@graphics-sig is watching rpms/xorg-x11-drv-intel

@weldr-sig is watching rpms/ghc-RSA
@weldr-sig is watching rpms/ghc-attoparsec-binary
@weldr-sig is watching rpms/ghc-authenticate-oauth
@weldr-sig is watching rpms/ghc-bindings-DSL
@weldr-sig is watching rpms/ghc-chunked-data
@weldr-sig is watching rpms/ghc-codec-rpm
@weldr-sig is watching rpms/ghc-concurrent-extra
@weldr-sig is watching rpms/ghc-cond
@weldr-sig is watching rpms/ghc-conduit-combinators
@weldr-sig is watching rpms/ghc-content-store
@weldr-sig is watching rpms/ghc-cpio-conduit
@weldr-sig is watching rpms/ghc-crypto-pubkey-types
@weldr-sig is watching rpms/ghc-generics-sop
@weldr-sig is watching rpms/ghc-gi-ggit
@weldr-sig is watching rpms/ghc-gi-gio
@weldr-sig is watching rpms/ghc-gi-glib
@weldr-sig is watching rpms/ghc-gi-gobject
@weldr-sig is watching rpms/ghc-gi-ostree
@weldr-sig is watching rpms/ghc-haskell-gi
@weldr-sig is watching rpms/ghc-haskell-gi-base
@weldr-sig is watching rpms/ghc-haskell-gi-overloading
@weldr-sig is watching rpms/ghc-hspec
@weldr-sig is watching rpms/ghc-hspec-core
@weldr-sig is watching rpms/ghc-hspec-discover
@weldr-sig is watching rpms/ghc-hspec-expectations
@weldr-sig is watching rpms/ghc-htoml
@weldr-sig is watching rpms/ghc-http-media
@weldr-sig is watching rpms/ghc-lens-aeson
@weldr-sig is watching rpms/ghc-listsafe
@weldr-sig is watching rpms/ghc-lzma-conduit
@weldr-sig is watching rpms/ghc-mono-traversable
@weldr-sig is watching rpms/ghc-natural-transformation
@weldr-sig is watching rpms/ghc-parsec-numbers
@weldr-sig is watching rpms/ghc-quickcheck-io
@weldr-sig is watching rpms/ghc-semver
@weldr-sig is watching rpms/ghc-servant
@weldr-sig is watching rpms/ghc-servant-client
@weldr-sig is watching rpms/ghc-servant-client-core
@weldr-sig is watching rpms/ghc-servant-foreign
@weldr-sig is watching rpms/ghc-servant-options
@weldr-sig is watching rpms/ghc-servant-server
@weldr-sig is watching rpms/ghc-string-conversions
@weldr-sig is watching rpms/ghc-string-qq
@weldr-sig is watching rpms/ghc-tar-conduit
@weldr-sig is watching rpms/ghc-unbounded-delays
@weldr-sig is watching rpms/ghc-vector-algorithms
@weldr-sig is watching rpms/ghc-wai-cors
@weldr-sig is watching rpms/ghc-wreq

affix is maintaining rpms/libmygpo-qt
affix is watching rpms/nagios
affix is watching rpms/nginx
affix is watching rpms/znc-infobot

alen is watching rpms/firefox

amitshah is maintaining rpms/pius
amitshah is maintaining rpms/qemu

andreyma is maintaining rpms/ucx

avesh is maintaining rpms/ima-evm-utils
avesh is maintaining rpms/libtnc
avesh is watching rpms/openpts
avesh is watching rpms/openswan
avesh is watching rpms/pam_ccreds
avesh is watching rpms/pam_passwdqc
avesh is watching rpms/passwdqc
avesh is maintaining rpms/strongswan
avesh is maintaining rpms/stunnel
avesh is maintaining rpms/tpm-quote-tools
avesh is maintaining rpms/tpm-tools
avesh is watching rpms/trousers

etingof is maintaining rpms/python-pyghmi

gnikandrov is watching rpms/setup

ignotusp is watching rpms/leechcraft
ignotusp is watching rpms/qxmpp-dev

itsbill is watching rpms/ratpoison

jefferson2z is watching rpms/godot

kir is watching rpms/criu

luismartingil is maintaining rpms/sipp

marcdeop is maintaining rpms/amarok
marcdeop is maintaining rpms/latte-dock
marcdeop is maintaining rpms/vim-omnicppcomplete

mbartos is watching rpms/ceelog
mbartos is maintaining rpms/libee
mbartos is maintaining rpms/libestr
mbartos is maintaining rpms/liblognorm
mbartos is watching rpms/libmongo-client
mbartos is watching rpms/libumberlog
mbartos is watching rpms/npth

mhabrnal is watching rpms/abrt
mhabrnal is maintaining rpms/abrt-addon-python3
mhabrnal is watching rpms/abrt-java-connector
mhabrnal is maintaining rpms/container-exception-logger
mhabrnal is watching rpms/gnome-abrt
mhabrnal is watching rpms/libreport

mildew is maintaining rpms/PEGTL
mildew is maintaining rpms/clevis
mildew is maintaining rpms/jose
mildew is maintaining rpms/json
mildew is maintaining rpms/luksmeta
mildew is maintaining rpms/sudo
mildew is maintaining rpms/tang
mildew is maintaining rpms/usbguard

mmahut is watching rpms/PySBIG
mmahut is maintaining rpms/PyXB
mmahut is watching rpms/PythonCard
mmahut is watching rpms/abgraph
mmahut is watching rpms/accrete
mmahut is watching rpms/astronomy-backgrounds
mmahut is watching rpms/astronomy-bookmarks
mmahut is maintaining rpms/bip
mmahut is maintaining rpms/boinc-client
mmahut is maintaining rpms/btrfs-progs
mmahut is watching rpms/bwping
mmahut is watching rpms/cdk
mmahut is maintaining rpms/celestia
mmahut is maintaining rpms/cfitsio
mmahut is maintaining rpms/cloudy
mmahut is watching rpms/comedilib
mmahut is maintaining rpms/cpl
mmahut is watching rpms/cvsgraph
mmahut is watching rpms/cvsplot
mmahut is watching rpms/cvsweb
mmahut is watching rpms/eboard
mmahut is watching rpms/evolution-zimbra
mmahut is maintaining rpms/extrema
mmahut is watching rpms/gcx
mmahut is maintaining rpms/gdal
mmahut is watching rpms/ggobi
mmahut is maintaining rpms/gnuradio
mmahut is watching rpms/gpredict
mmahut is watching rpms/grc
mmahut is watching rpms/imapsync
mmahut is watching rpms/ircd-ratbox
mmahut is watching rpms/irssi
mmahut is maintaining rpms/jday
mmahut is watching rpms/libopensync-plugin-sunbird
mmahut is watching rpms/mencal
mmahut is watching rpms/mod_scgi
mmahut is maintaining rpms/munipack
mmahut is watching rpms/nexcontrol
mmahut is watching rpms/nightfall
mmahut is maintaining rpms/octave
mmahut is watching rpms/openuniverse
mmahut is watching rpms/orsa
mmahut is watching rpms/perl-ServiceNow-API
mmahut is maintaining rpms/planets
mmahut is maintaining rpms/pp3
mmahut is watching rpms/pyephem
mmahut is watching rpms/python-cli
mmahut is maintaining rpms/python-numdisplay
mmahut is watching rpms/python-rhev
mmahut is watching rpms/ratbox-services
mmahut is watching rpms/redmode
mmahut is watching rpms/rhevsh
mmahut is watching rpms/rmap
mmahut is maintaining rpms/rt3
mmahut is watching rpms/rubygem-archivist
mmahut is maintaining rpms/rubygem-oauth
mmahut is maintaining rpms/saoimage
mmahut is maintaining rpms/sextractor
mmahut is watching rpms/siril
mmahut is watching rpms/spacechart
mmahut is maintaining rpms/starplot
mmahut is maintaining rpms/starplot-contrib
mmahut is maintaining rpms/starplot-gliese3
mmahut is maintaining rpms/starplot-yale5
mmahut is watching rpms/sub2srt
mmahut is maintaining rpms/sunbird
mmahut is maintaining rpms/swarp
mmahut is maintaining rpms/wxPython
mmahut is watching rpms/xstar
mmahut is watching rpms/xvarstar
mmahut is watching rpms/yakuake

nguzman is maintaining rpms/eclipse-egit

pgibson is watching rpms/pam

robled is maintaining rpms/python-kaptan
robled is maintaining rpms/python-libtmux
robled is maintaining rpms/rocket-depot

romal is maintaining rpms/man-pages-de
romal is watching rpms/nagios
romal is maintaining rpms/usb_modeswitch
romal is watching rpms/usb_modeswitch-data

rpitonak is maintaining container/nodejs
rpitonak is maintaining container/php
rpitonak is maintaining modules/httpd
rpitonak is watching modules/nginx
rpitonak is maintaining modules/ntp
rpitonak is maintaining modules/perl
rpitonak is maintaining modules/php
rpitonak is maintaining modules/postgresql
rpitonak is maintaining modules/proftpd

rspanton is maintaining rpms/pymunk

squallbayu is watching rpms/gnome-control-center
squallbayu is watching rpms/gnome-desktop3

sspreitz is maintaining rpms/consul
sspreitz is maintaining rpms/numix-gtk-theme
sspreitz is maintaining rpms/numix-icon-theme
sspreitz is maintaining rpms/numix-icon-theme-circle
sspreitz is maintaining rpms/stress-ng
sspreitz is watching rpms/strongswan
svahl is watching rpms/compiz-manager

svahl is watching rpms/devilspie
svahl is watching rpms/dragonplayer
svahl is watching rpms/kcoloredit
svahl is watching rpms/kerry
svahl is watching rpms/kgrab
svahl is watching rpms/kiconedit
svahl is watching rpms/kmid
svahl is watching rpms/konq-plugins
svahl is watching rpms/koverartist
svahl is watching rpms/ksig
svahl is watching rpms/libzip
svahl is watching rpms/polyester
svahl is watching rpms/polyester3
svahl is watching rpms/stalonetray

tnorth is watching rpms/GREYCstoration
tnorth is maintaining rpms/LabPlot
tnorth is maintaining rpms/ViTables
tnorth is maintaining rpms/alliance
tnorth is maintaining rpms/autojump
tnorth is maintaining rpms/avr-binutils
tnorth is maintaining rpms/avr-gcc
tnorth is watching rpms/avr-gdb
tnorth is maintaining rpms/avr-libc
tnorth is maintaining rpms/blosc
tnorth is maintaining rpms/dia-optics
tnorth is watching rpms/gwave
tnorth is maintaining rpms/kicad
tnorth is maintaining rpms/latexila
tnorth is maintaining rpms/liborigin
tnorth is maintaining rpms/magic
tnorth is maintaining rpms/pikdev
tnorth is maintaining rpms/python-anfft
tnorth is maintaining rpms/python-blosc
tnorth is watching rpms/python-matplotlib
tnorth is maintaining rpms/python-numexpr
tnorth is maintaining rpms/python-tables
tnorth is watching rpms/rawtherapee
tnorth is maintaining rpms/sane-backends
tnorth is maintaining rpms/toped

tstclair is maintaining rpms/condor
tstclair is maintaining rpms/containernetworking-cni
tstclair is maintaining rpms/curator
tstclair is maintaining rpms/gmock
tstclair is maintaining rpms/go-bindata
tstclair is maintaining rpms/gtest
tstclair is watching rpms/kryo-serializers
tstclair is maintaining rpms/kubernetes
tstclair is maintaining rpms/picojson
tstclair is watching rpms/zookeeper

usercont is maintaining rpms/colin
usercont is maintaining rpms/conu
usercont is maintaining rpms/packit
usercont is maintaining rpms/python-docker
usercont is maintaining rpms/python-ogr
usercont is maintaining rpms/rudesocket

vbatts is maintaining rpms/cadvisor
vbatts is watching rpms/docker
vbatts is maintaining rpms/flannel
vbatts is maintaining rpms/go-bindata
vbatts is maintaining rpms/go-srpm-macros
vbatts is maintaining rpms/golang
vbatts is maintaining rpms/golang-bitbucket-kardianos-osext
vbatts is maintaining rpms/golang-github-BurntSushi-toml
vbatts is maintaining rpms/golang-github-SeanDolphin-bqschema
vbatts is maintaining rpms/golang-github-Sirupsen-logrus
vbatts is maintaining rpms/golang-github-bmizerany-assert
vbatts is maintaining rpms/golang-github-bmizerany-pat
vbatts is maintaining rpms/golang-github-codegangsta-cli
vbatts is maintaining rpms/golang-github-coreos-go-etcd
vbatts is maintaining rpms/golang-github-coreos-go-log
vbatts is maintaining rpms/golang-github-coreos-go-systemd
vbatts is maintaining rpms/golang-github-davecgh-go-spew
vbatts is maintaining rpms/golang-github-docker-libcontainer
vbatts is maintaining rpms/golang-github-docker-libtrust
vbatts is maintaining rpms/golang-github-elazarl-go-bindata-assetfs
vbatts is maintaining rpms/golang-github-emicklei-go-restful
vbatts is maintaining rpms/golang-github-ghodss-yaml
vbatts is maintaining rpms/golang-github-golang-glog
vbatts is maintaining rpms/golang-github-google-gofuzz
vbatts is maintaining rpms/golang-github-goraft-raft
vbatts is maintaining rpms/golang-github-gorilla-context
vbatts is maintaining rpms/golang-github-gorilla-mux
vbatts is maintaining rpms/golang-github-influxdb-go-cache
vbatts is maintaining rpms/golang-github-influxdb-gomdb
vbatts is maintaining rpms/golang-github-influxdb-influxdb
vbatts is maintaining rpms/golang-github-jmhodges-levigo
vbatts is maintaining rpms/golang-github-kr-fs
vbatts is maintaining rpms/golang-github-kr-pretty
vbatts is maintaining rpms/golang-github-kr-text
vbatts is maintaining rpms/golang-github-mitchellh-goamz
vbatts is maintaining rpms/golang-github-mitchellh-mapstructure
vbatts is maintaining rpms/golang-github-mreiferson-go-httpclient
vbatts is maintaining rpms/golang-github-onsi-ginkgo
vbatts is maintaining rpms/golang-github-onsi-gomega
vbatts is maintaining rpms/golang-github-racker-perigee
vbatts is maintaining rpms/golang-github-rackspace-gophercloud
vbatts is maintaining rpms/golang-github-rcrowley-go-metrics
vbatts is maintaining rpms/golang-github-skratchdot-open-golang
vbatts is maintaining rpms/golang-github-stretchr-objx
vbatts is maintaining rpms/golang-github-stretchr-testify
vbatts is maintaining rpms/golang-github-syndtr-gocapability
vbatts is maintaining rpms/golang-github-tchap-go-patricia
vbatts is maintaining rpms/golang-github-tonnerre-golang-pretty
vbatts is maintaining rpms/golang-github-vaughan0-go-ini
vbatts is maintaining rpms/golang-github-vishvananda-netlink
vbatts is watching rpms/golang-github-vishvananda-netns
vbatts is maintaining rpms/golang-googlecode-gcfg
vbatts is maintaining rpms/golang-googlecode-go-crypto
vbatts is maintaining rpms/golang-googlecode-go-exp
vbatts is maintaining rpms/golang-googlecode-goauth2
vbatts is maintaining rpms/golang-googlecode-gogoprotobuf
vbatts is maintaining rpms/golang-googlecode-gomock
vbatts is maintaining rpms/golang-googlecode-google-api-client
vbatts is maintaining rpms/golang-googlecode-goprotobuf
vbatts is maintaining rpms/golang-googlecode-log4go
vbatts is maintaining rpms/golang-googlecode-net
vbatts is maintaining rpms/golang-googlecode-sqlite
vbatts is maintaining rpms/golang-googlecode-text
vbatts is maintaining rpms/golang-googlecode-tools
vbatts is maintaining rpms/golang-googlecode-uuid
vbatts is maintaining rpms/golang-gopkg-check
vbatts is maintaining rpms/golang-gopkg-yaml
vbatts is maintaining rpms/kubernetes

vicodan is watching rpms/gnome-backgrounds
vicodan is watching rpms/gnome-icon-theme
vicodan is watching rpms/gnome-media
vicodan is watching rpms/gpointing-device-settings
vicodan is watching rpms/libmate
vicodan is watching rpms/libmatecomponent
vicodan is watching rpms/libmatecomponentui
vicodan is watching rpms/libmatenotify
vicodan is watching rpms/libmateui
vicodan is watching rpms/mate-corba
vicodan is watching rpms/mate-keyring
vicodan is watching rpms/trustyrc

vpolasek is maintaining rpms/scap-security-guide

yuwata is watching rpms/dracut
yuwata is watching rpms/eigen3
yuwata is watching rpms/systemd


Pierre

[Michel Alexandre Salim]

On Tue, 2020-07-07 at 10:30 +0200, Pierre-Yves Chibon wrote:
>  On Tue, Jul 07, 2020 at 08:17:00AM +0000, Mattia Verga wrote:
>  > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
>  > > Good Morning Everyone,
>  > > 
>  > > The list is slowly going down, we have now 38 accounts that are
>  > > still
>  > > problematic, they have all received several personal emails over
>  > > the last few
>  > > weeks and none but one reacted.
>  > > I will likely start to ping FESCo about them starting next week.
>  > > ...
>  > 
>  >  From a quick look to that list, there are some users that have no 
>  > package assigned... I wonder if the unresponsive maintainer
>  > process 
>  > implies the user to be removed from the packager group when their 
>  > packages get orphaned and the user has no more any package
>  > associated to 
>  > their account.
>  
>  The source of info is: 
>  https://src.fedoraproject.org/extras/pagure_bz.json
>  which includes people that are packagers as well as people who are
>  watching the
>  packages (ie who asked to be included in the CC list on bugzilla).
>   
Should we make the script more robust and ignore invalid watcher
emails? Seems worrying if someone who's not even a packager can block
packager changes from being reflected in Bugzilla.

Regards,

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

[Pierre-Yves Chibon]

On Tue, Jul 07, 2020 at 10:38:01AM -0700, Michel Alexandre Salim wrote:
>  On Tue, 2020-07-07 at 10:30 +0200, Pierre-Yves Chibon wrote:
>  > On Tue, Jul 07, 2020 at 08:17:00AM +0000, Mattia Verga wrote:
>  > > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
>  > > > Good Morning Everyone,
>  > > > 
>  > > > The list is slowly going down, we have now 38 accounts that are
>  > > > still
>  > > > problematic, they have all received several personal emails over
>  > > > the last few
>  > > > weeks and none but one reacted.
>  > > > I will likely start to ping FESCo about them starting next week.
>  > > > ...
>  > > 
>  > >  From a quick look to that list, there are some users that have no 
>  > > package assigned... I wonder if the unresponsive maintainer
>  > > process 
>  > > implies the user to be removed from the packager group when their 
>  > > packages get orphaned and the user has no more any package
>  > > associated to 
>  > > their account.
>  > 
>  > The source of info is: 
>  > https://src.fedoraproject.org/extras/pagure_bz.json
>  > which includes people that are packagers as well as people who are
>  > watching the
>  > packages (ie who asked to be included in the CC list on bugzilla).
>  > 
>  
>  Should we make the script more robust and ignore invalid watcher
>  emails? Seems worrying if someone who's not even a packager can block
>  packager changes from being reflected in Bugzilla. 
As you can see in this JSON there is no difference between maintainers and
watchers, so the script syncing to bugzilla does not have this information.
I think that asking FESCo for a policy on how to deal with this + an automated
way to detect this situation (which we didn't really have so far) may be
sufficient. However, if this situation happens too frequently, and leads to too
much manual work to clean things up, we may need to see about somehow adding
this information to the JSON file and teaching the script the difference.
It would increase the load on bugzilla though :(

Pierre

[Kevin Fenzi]

On Wed, Jul 08, 2020 at 09:25:32AM +0200, Pierre-Yves Chibon wrote:
>  On Tue, Jul 07, 2020 at 10:38:01AM -0700, Michel Alexandre Salim
> wrote:
>  > Should we make the script more robust and ignore invalid watcher
>  > emails? Seems worrying if someone who's not even a packager can block
>  > packager changes from being reflected in Bugzilla.
>  
>  As you can see in this JSON there is no difference between maintainers and
>  watchers, so the script syncing to bugzilla does not have this information.
>  I think that asking FESCo for a policy on how to deal with this + an automated
>  way to detect this situation (which we didn't really have so far) may be
>  sufficient. However, if this situation happens too frequently, and leads to too
>  much manual work to clean things up, we may need to see about somehow adding
>  this information to the JSON file and teaching the script the difference.
>  It would increase the load on bugzilla though :( 
In the ideal world, we would just add checks so that people couldn't get
into this state. But thats going to require a lot of coordination/those
checks might be very difficult right now. I wonder though, if we could
get the new account system to help us here: I think there was a plan to
have it allow for a 'bugzilla email'. Could it perhaps also verify the
bugzilla email and have some 'bugzilla ok' property? 

Then, pagure could check it before allowing someone to watch/own/be
point of contact on a package and tell them to go set it before
allowing?

kevin