Explain the data management workflows cf. github issue

ome / omero-guide-introduction

BSD 2-Clause "Simplified" License

0 stars 5 forks source link

Explain the data management workflows cf. github issue #11

Closed pwalczysko closed 4 years ago

pwalczysko commented 4 years ago

see https://github.com/ome/omero-guide-introduction/issues/10

This explains the new de facto status of the linking behaviour of OMERO.web.

Do not merge this until the https://github.com/ome/omero-web/pull/199 is merge I would say.

--on-hold

pwalczysko commented 4 years ago

The travis failure seems to claim that linkchecker is the failing component. Checked all the links and they seem fine.

jburel commented 4 years ago

This is the problem we keep having with the idr links. (line 42) broken https://idr.openmicroscopy.org/webclient/?show=run-5403 - Exceeded 30 redirects. writing output... [ 50%] data-publication I will push commit to master excluding that check

pwalczysko commented 4 years ago

added on hold label as the functionality itself has not been merged yet

pwalczysko commented 4 years ago

Now that https://github.com/ome/omero-web/pull/199#pullrequestreview-486599072 is merged, what would be the best timing with this PR ? Probably depends on the release date of omero-web ? Should I relist ?

sbesson commented 4 years ago

https://github.com/ome/omero-guide-introduction/pull/11#issuecomment-690988477 brings a general wonder I have about the guides. Especially with the decoupled components and quick release process, what is the mechanism for expressing the minimal set of requirements required for a given feature? Or are we silently assuming that the guides assume the latest versions of each component are installed?

pwalczysko commented 4 years ago

Or are we silently assuming that the guides assume the latest versions of each component are installed?

This is not answering the question, (I would say the answer is yes, unless explicitly stated otherwise, cf. QuPath guide https://omero-guides.readthedocs.io/en/latest/qupath/docs/qupath.html#resources, where the version is specified in Resources). But generally, to explain the history, as the guides "came" from outreach, the versions were (and are) specified in the pdf, see https://downloads.openmicroscopy.org/presentations/2020/Paris/Paris_2020_walkthrough.pdf

sbesson commented 4 years ago

Thanks for the answer, it's really useful. In the case of this PR, does this mean Resources (or Setup?) should include OMERO.web 5.8.0 or later ?

jburel commented 4 years ago

in most cases the features are common to all version. If there is a change we could clarify and add for example from version xxx next to the feature described. For the analysis part, it is a bit easier in the sense that the version is pinned in the environment.yml file and can be used as a reference

sbesson commented 4 years ago

If there is a change we could clarify and add for example from version xxx next to the feature described.

That's certainly more targeted to the relevant feature than editing the global resources section. A relevant built-in Sphinx markup that could be considered would be versionchanged or versionadded.

pwalczysko commented 4 years ago

Merging, as OMERO.web 5.8.0 is released.