new packages review tickets

[Mattia Verga]

Hi all,

now that we have new detailed statistics about new package review 
tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would like 
to make some cleanings... at the time I'm writing, there are 517 tickets 
listed as new, many of them are older than 5 years!

The first steps I would like to do, if FESCO and community agree, are:

- some of these tickets are marked as "dependency rejected"; that means 
they depend on other package review tickets that were rejected, for 
whichever reason, so they will never get approved either. I would like 
to just close these (there are 3 tickets in this state)
- following the Policy for stalled package reviews [1], I would like to 
mass comment on tickets submitted before 1/1/2017 (more than 3 years 
old) asking the submitter if they're still interested in continue with 
the review process and mark the ticket as NEEDINFO. After one month 
without reply I will close the ticket, as per policy.

Then there are 352 tickets listed as "review in progress", but that's 
also not true. Here we have tickets with review-flag set to ? (review in 
progress) or + (package approved) since 2013. There are even some 
tickets for which the git repo as been generated.
These tickets probably need a manual check to choose the best course of 
action. Some of those packages have been approved and imported in 
Fedora, some of these have been later retired also from repositories... 
but the review ticket has never been closed.
I would propose to:

- if the package got approved and it's still in repos, just close the 
review ticket as CURRENTRELEASE
- if the package got approved and was later removed from repos, just 
close the review ticket as NOTABUG
- if the package got approved before 1/1/2019, but never imported in 
repos, clear the review-flag and assignee and mark as NEEDINFO from the 
submitter asking if they're still interested in this (we probably need 
to decide what to do if the git repo has been already set up)
- if the package got approved before 1/1/2020, but never imported in 
repos, do not clear the approval and mark as NEEDINFO from the submitter 
asking if they're still interested in this
- for tickets with last change marked before 1/1/2019, if the 
review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from 
either the submitter or the reviewer

Let me know if you agree (or disagree) with this proposal.
Mattia

[1] 
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitt...

[Igor Raits]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 2020-05-24 at 08:02 +0000, Mattia Verga via devel wrote:
>  Hi all, 
Hey,

>  now that we have new detailed statistics about new package review 
>  tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would
>  like 
>  to make some cleanings... at the time I'm writing, there are 517
>  tickets 
>  listed as new, many of them are older than 5 years!
>  
>  The first steps I would like to do, if FESCO and community agree,
>  are:
>  
>  - some of these tickets are marked as "dependency rejected"; that
>  means 
>  they depend on other package review tickets that were rejected, for 
>  whichever reason, so they will never get approved either. I would
>  like 
>  to just close these (there are 3 tickets in this state)
>  - following the Policy for stalled package reviews [1], I would like
>  to 
>  mass comment on tickets submitted before 1/1/2017 (more than 3 years 
>  old) asking the submitter if they're still interested in continue
>  with 
>  the review process and mark the ticket as NEEDINFO. After one month 
>  without reply I will close the ticket, as per policy.
>  
>  Then there are 352 tickets listed as "review in progress", but
>  that's 
>  also not true. Here we have tickets with review-flag set to ? (review
>  in 
>  progress) or + (package approved) since 2013. There are even some 
>  tickets for which the git repo as been generated.
>  These tickets probably need a manual check to choose the best course
>  of 
>  action. Some of those packages have been approved and imported in 
>  Fedora, some of these have been later retired also from
>  repositories... 
>  but the review ticket has never been closed.
>  I would propose to:
>  
>  - if the package got approved and it's still in repos, just close
>  the 
>  review ticket as CURRENTRELEASE
>  - if the package got approved and was later removed from repos, just 
>  close the review ticket as NOTABUG
>  - if the package got approved before 1/1/2019, but never imported in 
>  repos, clear the review-flag and assignee and mark as NEEDINFO from
>  the 
>  submitter asking if they're still interested in this (we probably
>  need 
>  to decide what to do if the git repo has been already set up)
>  - if the package got approved before 1/1/2020, but never imported in 
>  repos, do not clear the approval and mark as NEEDINFO from the
>  submitter 
>  asking if they're still interested in this
>  - for tickets with last change marked before 1/1/2019, if the 
>  review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO
>  from 
>  either the submitter or the reviewer
>  
>  Let me know if you agree (or disagree) with this proposal. 
This is great idea! If you need any help with bugzilla API or anything
like that - let me know.

>  Mattia
>  
>  [1] 
>
> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitt...
>  
>  _______________________________________________
>  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] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7KeaAACgkQEV1auJxc
> Hh7O/A/8DPCzwNG6prT4/As94YOYPLrwBcS7qjC0FZZlB3Edw/8MifqqNJHSzk2W
> 032w3eHxpUuHkgBW+tl6cAC2YdypaxkApwRHCQE/jJMUNDG3Xb7tg3qr8HNeHeho
> kdeVIkt8mBhGIPWT57EBXwAUm5Erl6nqrcqTpyTdh3QMGmB4KxNymzOY8I3NZpZA
> OKLZL2zgq2/0YN6jcgZoRSp+eLM3Nvtq/lyDRn2/zaXb6G7OT4XnCa4H1W9wMBYa
> IZmEB0n+LZFKnE7ypi7NWZnNaXzwhRMllEaO96H1f188NJoEsSIfFgZZpJQCfzXc
> 8LF0Gkqz5E+6Qw0vaQrfuLkWiGvsmdSMG3MduSNWkt2ts1qvgZFbr1YAnC7Znawd
> muycIFOgGhH8RK68ojmUrdbTHF3jzsbW6Uusjt9k5bwmYfLtYSGSWfpE8VAxLOyy
> HVBjM6AEWSVupcZSeTuDKIGvWX6l2jyjJY+6ltIEg5DrIAnm+7u49hkwGeX1KOws
> xmbQ1ZP6WoWc8cffH6xaQJgy+Eosfnm0bxtXHU/ZsbIv01aAa9KiCuBquGP5evOf
> EwEAXY78/V2SwVVCSOsq6kAPqx0+r81+dTIAWU6iIPB4VJJeiwAAV+h+kOn7VuQL
> NpEPzO9GOxPYhSy+x0UXIjx+LKLAD4Oi772YHr3iTfpkxEy2QKg=
> =itvp
> -----END PGP SIGNATURE-----

[Mattia Verga]

Il 24/05/20 15:41, Igor Raits ha scritto:
>  This is great idea! If you need any help with bugzilla API or anything
>  like that - let me know.
>
>  
Yeah, I think I need some help in getting flags resetted.

I would like to reset the 'needinfo' flag and the 'fedora-review' flag. 
Accordingly to 
https://bugzilla.readthedocs.io/en/latest/api/core/v1/bug.html#update-bug 
setting 'X' as status should reset the flag, but running:

     flags = tk.bug.flags
     for idx, flag in enumerate(flags):
         if 'name' in flag and flag['name'] in ['needinfo', 
'fedora-review']:
             flags[idx]['status'] = 'X'

     update = bz.build_update(comment=comments['reset_needinfo'], 
flags=flags,
                          status='NEW', reset_assigned_to=True)
     try:
         bz.update_bugs([tk.bug.id], update)
     except Exception:
         log.error(f'Resetting bug {tk.bug.id} failed: ', exc_info=1)

results in

xmlrpc.client.Fault: <Fault 32000: 'There is no user account given.'>

I suppose I'm missing something, do you have any idea?

[Fabio Valentini]

On Thu, May 28, 2020 at 6:58 PM Mattia Verga via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Il 24/05/20 15:41, Igor Raits ha scritto:
>  >
>  > This is great idea! If you need any help with bugzilla API or anything
>  > like that - let me know.
>  >
>  >
>  Yeah, I think I need some help in getting flags resetted.
>
>  I would like to reset the 'needinfo' flag and the 'fedora-review' flag.
>  Accordingly to
>  https://bugzilla.readthedocs.io/en/latest/api/core/v1/bug.html#update-bug
>  setting 'X' as status should reset the flag, but running:
>
>       flags = tk.bug.flags
>       for idx, flag in enumerate(flags):
>           if 'name' in flag and flag['name'] in ['needinfo',
>  'fedora-review']:
>               flags[idx]['status'] = 'X'
>
>       update = bz.build_update(comment=comments['reset_needinfo'],
>  flags=flags,
>                            status='NEW', reset_assigned_to=True)
>       try:
>           bz.update_bugs([tk.bug.id], update)
>       except Exception:
>           log.error(f'Resetting bug {tk.bug.id} failed: ', exc_info=1)
>
>  results in
>
>  xmlrpc.client.Fault: <Fault 32000: 'There is no user account given.'>
>
>  I suppose I'm missing something, do you have any idea? 
Since bugzilla keeps track of which user set which flag, do you maybe
need to specify which user's needinfo flag you want to clear?

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/[e-mail]

[Mattia Verga]

Il 28/05/20 19:04, Fabio Valentini ha scritto:
>  Since bugzilla keeps track of which user set which flag, do you maybe
>  need to specify which user's needinfo flag you want to clear?
>
>  Fabio
>  
I'm already passing all the flag object properties, id included:

> >> bug = bz.getbug(1730464)
> >> flags = bug.flags
> >> flags 
[{'status': '?', 'name':
'fedora-review', 'modification_date': <DateTime 
'20200528T16:04:43' at 0x7f2af35903a0>, 'creation_date': <DateTime 
'20200528T16:04:43' at 0x7f2af3590400>, 'is_active': 1,
'type_id': 65, 
'id': 4045137, 'setter': &#39;mattia.verga(a)protonmail.com&#39;},
{'requestee': 
&#39;mattia.verga(a)protonmail.com&#39;, 'status': '?', 'name':
'needinfo', 
'modification_date': <DateTime '20200528T16:36:27' at
0x7f2af3590490>, 
'creation_date': <DateTime '20200528T16:36:27' at 0x7f2af35904c0>, 
'is_active': 1, 'type_id': 16, 'id': 4045139, 'setter': 
&#39;mattia.verga(a)protonmail.com&#39;}]
> >> for idx, flag in enumerate(flags): 
...     if
'name' in flag and flag['name'] in ['needinfo',
'fedora-review']:
...             flags[idx]['status'] = 'X'
...
> >> update = bz.build_update(flags=flags)
> >> update 
{'flags': [{'status': 'X', 'name':
'fedora-review', 'modification_date': 
<DateTime '20200528T16:04:43' at 0x7f2af35903a0>, 'creation_date': 
<DateTime '20200528T16:04:43' at 0x7f2af3590400>, 'is_active': 1, 
'type_id': 65, 'id': 4045137, 'setter':
&#39;mattia.verga(a)protonmail.com&#39;}, 
{'requestee': &#39;mattia.verga(a)protonmail.com&#39;, 'status':
'X', 'name': 
'needinfo', 'modification_date': <DateTime '20200528T16:36:27'
at 
0x7f2af3590490>, 'creation_date': <DateTime '20200528T16:36:27' at 
0x7f2af35904c0>, 'is_active': 1, 'type_id': 16, 'id': 4045139,
'setter': 
&#39;mattia.verga(a)protonmail.com&#39;}]}

I've also tried to change the setter or the requestee, since the error 
mentions a 'user account', but I always end with an error.

Mattia

[Kevin Fenzi]

On Sun, May 24, 2020 at 08:02:09AM +0000, Mattia Verga via devel wrote:
>  Hi all,
>  
>  now that we have new detailed statistics about new package review 
>  tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would like 
>  to make some cleanings... at the time I'm writing, there are 517 tickets 
>  listed as new, many of them are older than 5 years!
>  
>  The first steps I would like to do, if FESCO and community agree, are:
>  
>  - some of these tickets are marked as "dependency rejected"; that means 
>  they depend on other package review tickets that were rejected, for 
>  whichever reason, so they will never get approved either. I would like 
>  to just close these (there are 3 tickets in this state)
>  - following the Policy for stalled package reviews [1], I would like to 
>  mass comment on tickets submitted before 1/1/2017 (more than 3 years 
>  old) asking the submitter if they're still interested in continue with 
>  the review process and mark the ticket as NEEDINFO. After one month 
>  without reply I will close the ticket, as per policy.
>  
>  Then there are 352 tickets listed as "review in progress", but that's 
>  also not true. Here we have tickets with review-flag set to ? (review in 
>  progress) or + (package approved) since 2013. There are even some 
>  tickets for which the git repo as been generated.
>  These tickets probably need a manual check to choose the best course of 
>  action. Some of those packages have been approved and imported in 
>  Fedora, some of these have been later retired also from repositories... 
>  but the review ticket has never been closed.
>  I would propose to:
>  
>  - if the package got approved and it's still in repos, just close the 
>  review ticket as CURRENTRELEASE
>  - if the package got approved and was later removed from repos, just 
>  close the review ticket as NOTABUG
>  - if the package got approved before 1/1/2019, but never imported in 
>  repos, clear the review-flag and assignee and mark as NEEDINFO from the 
>  submitter asking if they're still interested in this (we probably need 
>  to decide what to do if the git repo has been already set up) 
Likely mark it dead.package if it never got imported... 

>  - if the package got approved before 1/1/2020, but never imported in
>
>  repos, do not clear the approval and mark as NEEDINFO from the submitter 
>  asking if they're still interested in this
>  - for tickets with last change marked before 1/1/2019, if the 
>  review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from 
>  either the submitter or the reviewer
>  
>  Let me know if you agree (or disagree) with this proposal. 
Sounds good to me! Thanks for working on this. 

kevin

[Dan Čermák]

Hi Mattia,

Mattia Verga via devel <devel(a)lists.fedoraproject.org&gt; writes:

>  Hi all,
>
>  now that we have new detailed statistics about new package review 
>  tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would like 
>  to make some cleanings... at the time I'm writing, there are 517 tickets 
>  listed as new, many of them are older than 5 years!
>
>  The first steps I would like to do, if FESCO and community agree, are:
>
>  - some of these tickets are marked as "dependency rejected"; that means 
>  they depend on other package review tickets that were rejected, for 
>  whichever reason, so they will never get approved either. I would like 
>  to just close these (there are 3 tickets in this state)
>  - following the Policy for stalled package reviews [1], I would like to 
>  mass comment on tickets submitted before 1/1/2017 (more than 3 years 
>  old) asking the submitter if they're still interested in continue with 
>  the review process and mark the ticket as NEEDINFO. After one month 
>  without reply I will close the ticket, as per policy.
>
>  Then there are 352 tickets listed as "review in progress", but that's 
>  also not true. Here we have tickets with review-flag set to ? (review in 
>  progress) or + (package approved) since 2013. There are even some 
>  tickets for which the git repo as been generated.
>  These tickets probably need a manual check to choose the best course of 
>  action. Some of those packages have been approved and imported in 
>  Fedora, some of these have been later retired also from repositories... 
>  but the review ticket has never been closed.
>  I would propose to:
>
>  - if the package got approved and it's still in repos, just close the 
>  review ticket as CURRENTRELEASE
>  - if the package got approved and was later removed from repos, just 
>  close the review ticket as NOTABUG
>  - if the package got approved before 1/1/2019, but never imported in 
>  repos, clear the review-flag and assignee and mark as NEEDINFO from the 
>  submitter asking if they're still interested in this (we probably need 
>  to decide what to do if the git repo has been already set up)
>  - if the package got approved before 1/1/2020, but never imported in 
>  repos, do not clear the approval and mark as NEEDINFO from the submitter 
>  asking if they're still interested in this
>  - for tickets with last change marked before 1/1/2019, if the 
>  review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from 
>  either the submitter or the reviewer
>
>  Let me know if you agree (or disagree) with this proposal. 
Sounds good to me. Thanks for taking care of this!


Cheers,

Dan

[Ben Cotton]

On Sun, May 24, 2020 at 4:03 AM Mattia Verga via devel
<devel(a)lists.fedoraproject.org&gt; wrote:

>  Let me know if you agree (or disagree) with this proposal. 
I like it. I'm happy to help and take the ongoing "enforcement" work
as part of the Program Manager's role if you don't want to stay on top
of this forever (although I'd probably do it once per release cycle,
which is still a big improvement on "once per every 5 years")

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 26, 2020 at 08:33:14AM -0400, Ben Cotton wrote:
>  On Sun, May 24, 2020 at 4:03 AM Mattia Verga via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  
>  > Let me know if you agree (or disagree) with this proposal.
>  
>  I like it. 
Let me add my +1 too. (Actually, I had some doubts about the details,
but I think taking *some* action is better than keeping the current
messy state. I think your proposal will be OK for 98% of the tickets,
and for the other ones, we can just reopen any ticket that got
mishandled. So there's no need to overthink this and figure out every
possible twist in advance.)

>  I'm happy to help and take the ongoing "enforcement"
> work
>  as part of the Program Manager's role if you don't want to stay on top
>  of this forever (although I'd probably do it once per release cycle,
>  which is still a big improvement on "once per every 5 years") 
That'd be great!

Zbyszek

[Mattia Verga]

Il 26/05/20 14:33, Ben Cotton ha scritto:
>  I like it. I'm happy to help and take the ongoing "enforcement" work
>  as part of the Program Manager's role if you don't want to stay on top
>  of this forever (although I'd probably do it once per release cycle,
>  which is still a big improvement on "once per every 5 years")
>  
I'm currently writing some code for running this automatically in 
review_stats [1].

I haven't pushed anything yet in the git repo, but I hope to have 
something ready in a week or so. I'm thinking to run a script once a day 
and starting with something "soft":
- for every review ticket which hasn't been updated for a year and 
WITHOUT fedora-review flag set, set the NEEDINFO flag asking the 
submitter if they're still interested in running the review process.
- for every review ticket which hasn't been updated for a year and WITH 
fedora-review flag set to '?' (review in progress), set the NEEDINFO 
flag asking the reviewer to try to move the review up.
- for every review ticket with NEEDINFO set more than one month ago 
against the submitter, close the ticket as DEADREVIEW
- for every review ticket with NEEDINFO set more than one month ago 
against the reviewer, reset fedora-flag status and the assignee

Then (or meanwhile), I think we should look manually into tickets with 
fedora-review flag set to '+' and not updated for more than one month to 
figure out cases where the package was imported and the ticket was never 
closed, or where the package was approved but never imported (and we 
should look to retire the git repo, if it had been set up).

I'll post here a notice when I have the code ready in the git repo.

Thanks
Mattia

[1] https://pagure.io/Fedora-Infra/review_stats

[Miroslav Suchý]

Dne 24. 05. 20 v 10:02 Mattia Verga via devel napsal(a):
>  - following the Policy for stalled package reviews [1], I would like
> to 
>  mass comment on tickets submitted before 1/1/2017 (more than 3 years 
>  old) asking the submitter if they're still interested in continue with 
>  the review process and mark the ticket as NEEDINFO. After one month 
>  without reply I will close the ticket, as per policy. 
-1
I had phase of life when I worked on these archaeologic tickets. I even managed to process
eight years old ticket!
Yes, for most tickets it was: Ping! Wait one month. Than one more gentle Ping! And if
submitter does not respond, then I
closed the ticket.
But I never done that en-masse. For every such ping, I was prepared to work on that
ticket.

It may sounds appealing to clean the plate and "resolve" a lot of tickets.
However, think about it from the other side:
somebody is waiting for review for years, then a ping will come, and if he responds, then
... nothing. Just "yeah, we
are not going to close this". That is not very welcome. :(

>  Then there are 352 tickets listed as "review in progress",
> but that's 
>  also not true. Here we have tickets with review-flag set to ? (review in 
>  progress) or + (package approved) since 2013. There are even some 
>  tickets for which the git repo as been generated.
>  These tickets probably need a manual check to choose the best course of 
>  action. Some of those packages have been approved and imported in 
>  Fedora, some of these have been later retired also from repositories... 
>  but the review ticket has never been closed.
>  I would propose to:
>  
>  - if the package got approved and it's still in repos, just close the 
>  review ticket as CURRENTRELEASE
>  - if the package got approved and was later removed from repos, just 
>  close the review ticket as NOTABUG
>  - if the package got approved before 1/1/2019, but never imported in 
>  repos, clear the review-flag and assignee and mark as NEEDINFO from the 
>  submitter asking if they're still interested in this (we probably need 
>  to decide what to do if the git repo has been already set up)
>  - if the package got approved before 1/1/2020, but never imported in 
>  repos, do not clear the approval and mark as NEEDINFO from the submitter 
>  asking if they're still interested in this
>  - for tickets with last change marked before 1/1/2019, if the 
>  review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from 
>  either the submitter or the reviewer 
+1

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 27, 2020 at 12:45:56PM +0200, Miroslav Suchý wrote:
>  It may sounds appealing to clean the plate and "resolve" a
> lot of
>  tickets. However, think about it from the other side: somebody is
>  waiting for review for years, then a ping will come, and if he
>  responds, then ... nothing. Just "yeah, we are not going to close
>  this". That is not very welcome. :( 
But if somebody is waiting for review for years, they (we?) are doing
something wrong. Even is a review is waiting for a few weeks, people
should ask on fedora-devel, or propose review swaps, or whatever. Just
keeping tickets forever doesn't seem like a good option either.

Zbyszek

[Stephen John Smoogen]

On Wed, 27 May 2020 at 10:35, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt;
wrote:

>  On Wed, May 27, 2020 at 12:45:56PM +0200, Miroslav Suchý wrote:
>  > It may sounds appealing to clean the plate and "resolve" a lot of
>  > tickets. However, think about it from the other side: somebody is
>  > waiting for review for years, then a ping will come, and if he
>  > responds, then ... nothing. Just "yeah, we are not going to close
>  > this". That is not very welcome. :(
>
>  But if somebody is waiting for review for years, they (we?) are doing
>  something wrong. Even is a review is waiting for a few weeks, people
>  should ask on fedora-devel, or propose review swaps, or whatever. Just
>  keeping tickets forever doesn't seem like a good option either.
>
>  
Well it is quite clear we are doing something wrong and have been for as
long as the project has been going on. Normally we seem to get some point
where some people say 'gee this is awful' and then do some sort of
herculean backlog cleanup or close-out but in the end we just don't have a
lot of people who have time to do the level of reviews needed anymore than
we have the people to do the package maintenance or a billion other things
which have piled up.

Package reviews are like dirty dishes and laundry to a lot of people and
there are always something they would rather do or HAVE to than do it.
Until someone removes the Somebody Else's Problem Field from it.. reviews
will pile up.



>  Zbyszek
>  _______________________________________________
>  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]
>  

-- 
Stephen J Smoogen.

[Jason Tibbitts]

I'll apologize in advance for rambling, but I've been kicking around
ideas in this space for very many years now.

> >>>> "SJS" == Stephen John Smoogen
> <smooge(a)gmail.com&gt; writes: 
SJS> Well it is quite clear we are doing something wrong and have been
SJS> for as long as the project has been going on.

It's true that we've basically always had a backlog of tickets.  To be
fair, it's not as bad now as it was at its worst.  I haven't looked at
the queue in a couple of years and while there are some familiar tickets
there (one is now over 14 years old) I see pretty much what I expect.

SJS> Package reviews are like dirty dishes and laundry to a lot of
SJS> people and there are always something they would rather do or HAVE
SJS> to than do it.  Until someone removes the Somebody Else's Problem
SJS> Field from it.. reviews will pile up.

Yes, but there are other factors.  For example, we almost never just say
"no", instead letting the tickets just sit there.  We must at some point
accept the fact that there are going to be pieces of software that
basically nobody cares about, and not say that absolutely everything has
to be part of the distribution proper.

Sometimes I wish we could separate out the different "domains" of
package acceptance and let different people (or even automated systems)
handle them.

For example, here's a dumb list:

1) Is the thing legally acceptable?
2) Does the thing build?
3) Does the package meet some minimal standard (installs without
dependency problems, doesn't obsolete glibc, doesn't drop junk all over
the filesystem, etc.)
4) Is the payload fit for purpose (software needs to run, content needs
to... be contenty, etc.)?
5) Is the packaging itself (specfile) maintainable (meets guidelines, etc.)?

If a script could drive by and say "yep, it still builds" every so
often, that would actually help quite a bit.  If someone could drive by 
and say "yep, the license stuff checks out" then that would free a
reviewer from having to do that.  (And back when I did reviews, I spent a
significant amount of time worrying about that.)

If I could run through, look at specfiles and red flag things which are
problematic without having to sign on to the entire process (wait for
builds, worry about licensing) then I might occasionally spend some time
doing that.

I wonder if it would be possible for review tickets to acquire a number
of flags instead of just the one fedora-review flag, and the package
would simply be acceptable when all of the flags are checked off.

And on a separate tack, I would love to see an alternate path to package
acceptance that goes through COPR.  So if a package (or stack of
packages) is functional and well-maintained in COPR, someone with
appropriate privileges could simply nominate it for inclusion in the
main repository.  Other folks could look, have a chance to comment, and
then if sufficient positive votes are collected, the repo is created.

I can see that being really incredibly useful for stacks of packages
(where the one desired packages has a whole tree of dependencies that
have to go in first).  Not only do these clog up the review queue and
make the situation look even more hopeless, but there are so many round
trips through the process that it's just incredibly painful.

And while I'm on a roll, is there any system at all that we could use
where I can look at a specfile and make comments on specific lines?  I
can do that in a PR in any forge; can we leverage that way of working
somehow?  Is there any crazy way that we could have new package
submissions be submitted as PRs against some base prototype package
repo, with the existing koji CI stuff automatically making sure that the
submission builds?

 - J<

[Kevin Fenzi]

On Wed, May 27, 2020 at 12:45:56PM +0200, Miroslav Suchý wrote:
>  
>  -1
>  I had phase of life when I worked on these archaeologic tickets. I even managed to
> process eight years old ticket!
>  Yes, for most tickets it was: Ping! Wait one month. Than one more gentle Ping! And if
> submitter does not respond, then I
>  closed the ticket.
>  But I never done that en-masse. For every such ping, I was prepared to work on that
> ticket.
>  
>  It may sounds appealing to clean the plate and "resolve" a lot of tickets.
> However, think about it from the other side:
>  somebody is waiting for review for years, then a ping will come, and if he responds, then
> ... nothing. Just "yeah, we
>  are not going to close this". That is not very welcome. :( 
Sure, but neither is endless silence. 

Perhaps when/if we do mass process tickets as proposed in this thread we
could add a bit about how to get sponsored (for needs sponsor tickets)
and ideas on how to get a review (for all). It may be that some people
don't know that you can often find people to swap reviews with, or that
sponsors want you to do reviews, etc. Adding that info might help some
fraction of these tickets...

kevin

[Mattia Verga]

Thanks for all the comments and ideas you posted.

I have opened a pull request [1] to automate some of the processes 
against review-stats. If accepted it will:

- Set NEEDINFO against submitter on tickets not assigned and not updated 
for more than one year
- Set NEEDINFO against reviewer on tickets assigned and not updated for 
more than one year
- Reset ticket status and assignee on tickets where the assignee has not 
replied to the NEEDINFO for more than 1 month
- Close tickets where the submitter has not replied to the NEEDINFO for 
more than 1 month

If it had to be run now, it would set the NEEDINFO flag on 465 tickets 
and it would close as DEADREVIEW 30 tickets. I've uploaded the logfile 
[2] if you want to check the correctness. That means that nearly the 50% 
of all opened review tickets are stale by more than one year...

Mattia

[1] https://pagure.io/fedora-infra/review_stats/pull-request/6
[2] https://mattia.fedorapeople.org/review_stats/log.txt