Open jiripospisil opened 4 months ago
It's completely optional to receive out of date notifications, so priority will not always come through.
I mean that's fine, this is just something extra for packagers who do receive these notifications. I guess technically you could add filtering based on the priority to package search or just show it next to the flag date.
I think the plan is to automate the up-to-date checks and remove the manual out-of-date button. It would be better to put effort into the nvchecker integration rather than adding more complexity to the out-of-date button. There are gitlab issues for manual user-to-user interaction.
I see, that's a bit unfortunate because I don't know how nvchecker could reliably determine the urgency and so you still wouldn't be able to prioritize important updates from the rest. Not sure I understand your last point, are you saying people should create gitlab issues if there's an important update not getting enough attention?
are you saying people should create gitlab issues if there's an important update not getting enough attention?
I don't know how you define an important update, but e.g. security issues should definitely be reported. As for not getting enough attention, there are often blockers that may be already reported on gitlab.
Hello, it would be nice if the "Flag Package Out-of-Date" page offered a way to communicate the importance of the new release so that packagers can prioritize their backlog. For example, a security release is more important than a regular maintenance release.
I'm thinking something like this with the Medium priority pre-selected:
You could argue that the flagger could just write the priority in the "message to developer" field but the point of doing it this way is that the format would be standardised (Priority:XXX) and packagers could create rules in their email clients to automatically assign labels and filter based on them.