Due to an influx of spam, we have had to temporarily disable account registrations. Please write an email to accountsupport@archlinux.org, with your desired username, if you want to get access. Sorry for the inconvenience.
@toolybird Did you get assigned/notified for that issue? This is a POC we are working on to automatically create issues (and/or MR eventually in the future) for new upstream releases (based on the nvchecker integration in devtools). We made sure to not assign bugwranglers to those (first of all because this is just a POC for now, and second of all because we're not sure about the usefulness of assigning bugwranglers to those. I think it might just be noise for you).
FYI, the issues are auto closing themselves when the matching version has been pushed to GitLab (on the next run of the CI). See gajim#3 (comment 194567) ;)
No, I just noticed it on my "rounds" and closed accordingly.
To be honest, I'm not a fan of this POC. We already have over 900!! packaging issues. The last thing we need is more "noise" when there are already solutions in place for tracking new pkg versions (the user driven "Flag Package Out-of-Date" system + individual PMs using nvchecker). Not only that, we have always "discouraged" issues for new pkg versions and previously issued a big fat warning deterring users from opening such tickets.
I personally monitor the overall number of open issues and actively strive to keep the number down. It's currently a lot better than the nearly 2K from a couple of years ago. But if this POC were implemented, I feel it would be somewhat deflating for the morale of present and future bug wranglers
Thanks for sharing your concerns. To give you a little more context about this POC, it is supposed to replace the current "Flag Package Out-of-Date" system at some point. Indeed, the "Flag Package Out-of-Date" system has numerous flaws. For instance, it is often used wrongly and/or abusively and it is not very transparent as it doesn't allow any (public) responses as to why certain upgrades takes some time. One of the idea of having an actual issue is to provide a public place to discuss eventual blockers for certain upgrades (e.g. python-paho-mqtt#1) instead of having users wondering what's going on and sometimes exposing some weird theories on Reddit
I get how the increased number of issues implied by this POC might be a concern for bug wranglers (for "stats" and morale), this is a fair point. Although, we are aiming to make those issues as much "self-managed" as possible, out of the bug wranglers' scope and completely opt-in:
"New version" issues are not assigned to bug wranglers (they are opened with the "confirmed" scope right away) and are generally meant for packagers (and for transparency with the community). If there's a blocker for a specific update, it can be expressed in the "New version" issue, but another issue dedicated to that bug/blocker should be created (if needed).
"New version" issues have a dedicated scope::out-of-date (see labels for that issue) which bug wranglers can hopefully filter out when it comes to "stats" (and morale) matters.
"New version" issues assignments will be fully opt-in via bugbuddy, based on the same mechanic that is currently used for "unconfirmed" issues (as said above, issues are automatically closed when the matching version is pushed, so no manual intervention are needed).