No such file or directory: '/opt/conda/lib/python3.9/site-packages/ronswanson/data/log_theme.ini' about ronswanson HOT 9 CLOSED

@volodymyrss should be fixed in the last upload to pypi. However, it might be best to clone or install directly from master if there are any other bugs at the moment for faster turnaround. Thanks!

from ronswanson.

Uff. I thought I had fixed that. Will correct.

from ronswanson.

Thanks it works now. I wonder how it works in relation to openjournals/joss-reviews#4969 , it has to be somehow well-defined version which is being reviewed. As it's iterative, it would be the master branch. But some commands in the doc would not work until the version is uploaded. Maybe this is not imporatant. It's more of a question to @dfm.

from ronswanson.

@volodymyrss the best approach is to review the development version of the software and then we always tag a new release at the end of the review to archive the reviewed version.

from ronswanson.

@volodymyrss the best approach is to review the development version of the software and then we always tag a new release at the end of the review to archive the reviewed version.

Ok, I see, the comments/issues can be on master.

But I suppose the approval should be on a fixed revision, right? Else there can be a change on the master branch which is not approved.
How do I track what I am approving?

In principle, this is the case not only for final approval but for every qualification.

E.g. if I check "[ ] Installation: Does installation proceed as outlined in the documentation?", how do I indicate that it this particular version which proceeds, but not the other one?

edit: it's like in the PR: a new commit can be made to break the approval.

from ronswanson.

@volodymyrss Good question! We typically are not strict about that for JOSS reviews - you're definitely not expected to go through the full checklist a second time when there is a final version minted. I'd say that this is partly because of logistics (the scope is too broad, and it's hard to synchronize the two reviews, for example), but also partly because the point of a JOSS review is more to provide constructive feedback than to bring a specific judgement. From my perspective, it's totally sufficient to make sure that at the time you're going through it, the development branch satisfies the criteria in the checklist. That being said, if there are elements that are brittle or give you other reasons to be concerned, it's good to note that, and when I'm reviewing I do sometimes quickly go through the checklist one last time before signing off, but that's certainly not required! Please let me know if you have further questions - I'm happy to continue this conversation!

from ronswanson.

@volodymyrss Good question! We typically are not strict about that for JOSS reviews - you're definitely not expected to go through the full checklist a second time when there is a final version minted. I'd say that this is partly because of logistics (the scope is too broad, and it's hard to synchronize the two reviews, for example), but also partly because the point of a JOSS review is more to provide constructive feedback than to bring a specific judgement. From my perspective, it's totally sufficient to make sure that at the time you're going through it, the development branch satisfies the criteria in the checklist.

I see, thanks.

That being said, if there are elements that are brittle or give you other reasons to be concerned, it's good to note that, and when I'm reviewing I do sometimes quickly go through the checklist one last time before signing off, but that's certainly not required! Please let me know if you have further questions - I'm happy to continue this conversation!

Installation is quite likely to break in the future, especially if the requirements are not frozen. I suppose this is normal and not a fault of the software.
Evolving requirements may even change the behavior, or at least performance.
If we are concerned here with making the review reproducible and verifiable, I'd attach some form of environment snapshot, with all fixed versions, in a container.

But at minimum, I could point out the revision I am looking at when making a statement.
Maybe your bot could make use of this information in the future.

from ronswanson.

Great - totally agreed! And thanks for the suggestion - I'll bring this point up with the other JOSS editors to see how we'd like to handle these versioning issues that you've brought up. Thanks again!!

from ronswanson.

Thanks to you! This is interesting.

from ronswanson.