When RRS/checkpkg is performing an upstream version checks using git, and cannot find any suitable tags in upstream git repository, it simply gives up and reports 'Unknown' for the version check. But there could be a fallback: we can check if there are any later commits after the commit we're currently fetching, and report if there are (for example, in this case the date of the new commit, its id, and how many commits are between would be useful).
The additional information could be displayed in the recipe details page, above the list of updates. I will try to come up with a way of indicating in the recipes table which unknown recipes have later commits. About the information on the later commits, would you like to see all the commits between the one we're currently fetching and the latest one found in the upstream repo? Or just the number of commits between the 2 and some details about the latest one and the one we are currently fetching? What should we display for the upstream commits? Just * Title * Date * ID Do we need anything else? Should we provide links to the upstream commits? Thanks!
Perhaps displaying the full list of commits isn't a good idea: there may be too many of them, and it'll be just clutter on screen. Recipe maintainers can always get this information directly from original repos if they need to. I'm fine with the just the overall number of new commits, and details about the latest and current commit (date, summary and details, commit id).
So, what about this: * In the recipes table, add a badge next to the status showing the number of additional commits found (see attached rrs-extra-commits-in-tables.png) * In the recipe details page, add a table with the details of the last commit fetched and the last commit found upstream. The table includes a heading with the number of additional commits found (see attached rrs-additional-commits-found.png). In the table, the commit title is a link to the upstream commit information. If this looks ok, I'll document all the design details. Otherwise, let me know what you'd like to change. Thanks!
Created attachment 2894 [details] rrs-additional-commits-found.png
Created attachment 2895 [details] rrs-extra-commits-in-tables.png
Seems fine to me, except: The recipe status on both screenshots in this case should not be "Unknown". If there are additional commits upstream, then it should be "Not updated". If the latest commit upstream is same as the commit we fetch, then it should be "Up-to-date".
Hmmm. When I initially designed this I guess the meaning of the recipe statuses was: Not updated: upstream version known and not matching our version. Not updated recipes always show the upstream version of the recipe and our version, like so http://recipes.yoctoproject.org/rrs/recipedetail/699/ Unknown: upstream version not known (therefore we can't tell whether it is or not up to date) What you are suggesting means that from now on we will have some 'not updated' recipes for which we know the upstream version, and other 'not updated' recipes for which we won't know the upstream version and that would look like the attached rrs-notupdated-noupstreamversion.png The 'Unknown' status then means ... well, I no longer know what it means :) It seems to me there is some potential for confusion there between Unknown recipes and Not updated recipes with unknown upstream versions. Somehow, keeping the latter as unknown (ie. upstream version not known) seems clearer. Having said that, I don't use the RRS, so it's the recipe maintainers call. Maybe we just need to change the 'unknown' status to something else, like: "broken" ;)
Created attachment 2896 [details] rrs-notupdated-noupstreamversion.png
No, that's not what I meant. The statuses that I want to have are: Can't be updated: - the recipe lists a reason for no-update Up-to-date: - latest upstream version known and matches our version or (if determining latest upstream version fails and we use a repo to fetch sources) - latest upstream commit known and matches our commit Not updated: - latest upstream version known and is newer than our version or (if determining latest upstream version fails and we use a repo to fetch sources) - latest upstream commit known and is newer than our commit Unknown - everything else Here's how the logic would look like: - check if the recipe lists a no-update reason, if so, set the status to 'can't be updated' - determine latest upstream version, if it matches, set the status to 'up-to'date', if it's newer, set the status to 'not updated' - if the recipe is fetching sources from git/svn, find out if there are newer commits. If there are, set the status to 'not updated', otherwise set the status to 'up to date' - otherwise set the status to 'unknown' Makes sense?
In this case, the latest screenshot you've attached would still show 'unknown' as it would do now, because it would simply fall through the logic to the end.
It almost makes sense. I just have one more question: > Here's how the logic would look like: > > - check if the recipe lists a no-update reason, if so, set the status to > 'can't be updated' > > - determine latest upstream version, if it matches, set the status to > 'up-to'date', if it's newer, set the status to 'not updated' > > - if the recipe is fetching sources from git/svn, find out if there are > newer commits. If there are, set the status to 'not updated', otherwise set > the status to 'up to date' Is this step run for all recipes, or only for recipes that in the previous step were marked as 'not updated'. If the former (for all recipes), does that mean that a recipe with matching upstream version can be 'not updated' (because newer commits have been found)? Sorry for all the questions, but it does help to understand things. Thanks! > > - otherwise set the status to 'unknown' > > Makes sense?
At any step, if the status has been set to something, we stop and do not proceed to the next step. If a status has been set, it's final. If you read the logic again with that in mind, I think it all should be sensible and clear. Which means that here: > - determine latest upstream version, if it matches, set the status to > 'up-to'date', if it's newer, set the status to 'not updated' > > - if the recipe is fetching sources from git/svn, find out if there are > newer commits. If there are, set the status to 'not updated', otherwise set > the status to 'up to date' the latter step would be run only if neither of the two conditions in the former step would be true. If we found a newer version, or if we are already at the latest version, then we simply stop and don't check if there are newer commits. We proceed to that check if the upstream version is somehow older, or if it wasn't determined at all.
So it seems we got to the bottom of it. There will indeed be 'not updated' recipes with unknown upstream versions, because the 'not updated' status will no longer be tied to a known, unmatching upstream version. From a jabber discussion: "There can be two reasons for a recipe being 'not updated' - the upstream version is newer, or (there are newer commits and the upstream version cannot be determined or is older). The reason is that there are many recipes nowadays which are not tied to any particular upstream version. For them, we need to track upstream commits instead. There are for instance, plenty of upstream projects which in theory do releases, but in practice go without a release for years, or are perpetually stuck in some beta cycle in that case, we have to fetch a particular commit instead. Or there are also upstreams which simply never do releases - each new commit is a release then"
Created attachment 2906 [details] Design - Handle upstream repos with no vesion tags
Created attachment 2907 [details] Design - Handle upstream repos with no version tags
Yep, I think this looks good now.
The current situation with this that I addressed the feature gap in the 'backend': http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143812.html but the RRS fronted needs a (hopefully simple) tweak of displaying the commit id that is suggested by the backend, and not just the latest version. The id is written into the csv output right after the update status.
RRS has been defunct for years, mark as obsolete.