You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Easiest to just immediately give example for one package:
Package "python" major version 3.11 was released on 2022-10-24 (i.e. 126 days ago) and was flagged out of date then. However, there have been 3.10.* minor releases updated on Arch since so the "out of date" flag gets reset until somebody notices and re-flags it. Thus the new flag date (currently 2022-12-24, 65 days ago) is grossly miss-representative. A possible (simple?) solution is to allow the flag raiser to enter a version number on the form so the flag is not cleared until the new update(s) is that version or beyond? Of course should allow the package maintainer to reset that field for the inevitable cases where the version is entered incorrectly.
Related to this is the case the Arch "python" package is currently 3.10.9 but the latest available is 3.10.10 (2022-02-08, 18 days ago), i.e. there is also a new minor update pending and there should be a way to flag that. So possibly a (more involved?) solution is to have 2 separate out-of-date flags, one for major releases and another for minor releases?
The text was updated successfully, but these errors were encountered:
This is not really an issue, maintainers shouldn't rely on the flagger to report the correct version but should always verify the latest release of upstream itself. So the flag being out of date isn't too much of an issue.
Our goal should be to have automatic flagging with nvhecker or some automatic mechanism and to stop allowing of manual flagging.
Another good example of this bug is seen today. Current Arch Python 3.11 on Arch is 156 days "out of date" since 3.12 was released on 2023-10-02. However, maintainer just released minor update 3.11.8 today so the package got un-flagged. It was immediately re-flagged but it is presented that it is only out of date from today.
This is not something which can be fixed because Archweb does not know the latest version of the package so an package update always clears the flagged flag. Furthermore we aim to stop letting users flag packages in general and are working towards nvchecker integration.
This bug was raised on Monday, 27 Feb 2023 on the old Arch bug tracker with the following description:
Easiest to just immediately give example for one package:
Package "python" major version 3.11 was released on 2022-10-24 (i.e. 126 days ago) and was flagged out of date then. However, there have been 3.10.* minor releases updated on Arch since so the "out of date" flag gets reset until somebody notices and re-flags it. Thus the new flag date (currently 2022-12-24, 65 days ago) is grossly miss-representative. A possible (simple?) solution is to allow the flag raiser to enter a version number on the form so the flag is not cleared until the new update(s) is that version or beyond? Of course should allow the package maintainer to reset that field for the inevitable cases where the version is entered incorrectly.
Related to this is the case the Arch "python" package is currently 3.10.9 but the latest available is 3.10.10 (2022-02-08, 18 days ago), i.e. there is also a new minor update pending and there should be a way to flag that. So possibly a (more involved?) solution is to have 2 separate out-of-date flags, one for major releases and another for minor releases?
The text was updated successfully, but these errors were encountered: