Arvados

2.7.0~rc1-1

arvados|6de571a660401585bc96dd92fd2563e9b64c58c6
arvados-workbench2|f6f88d9ca9cdeeeebfadcfe999789bfb9f69e5c6

run-tests: #6021
workbench2-run-tests: #840

build-and-publish-rc-packages: #197
workbench2-build-release-candidate-package: #125

2.7.0~rc2-1

arvados|b20fb44b419ba6dd800874552bcfb5b87479611d
arvados-workbench2|d0c19f9eb52b9230d176a6c6e9e7e941c89d9e05

build-and-publish-rc-packages: #199
workbench2-build-release-candidate-package: #127
docker-jobs-image-release: #59

2.7.0~rc3-1

arvados|1fa83e67963bf49010b502ebf12f3b716ed6df7f
arvados-workbench2|ed1e56fa432068125967ad3128d224153c157f25

build-and-publish-rc-packages: #200
workbench2-build-release-candidate-package: #127
docker-jobs-image-release: #60

2.7.0~rc4-1

arvados|6bed090af13bba56d6cfe5f5a96add95000fa87c
arvados-workbench2|6f8dcb2b13f3058db656908fb26b09e23b527f08

run-tests: #6059
workbench2-run-tests: #853

build-and-publish-rc-packages: #201
workbench2-build-release-candidate-package: #130
docker-jobs-image-release: #61

Thank you for the draft release notes, I know it takes a lot of work to pull together.

A couple of style/voice/tone suggestions for the future (this is intended to be constructive criticism):

In general, people don't care what we did, they care about the ways that the software has changed, and more specifically, the benefits resulting from the changes in the release.

For example, some notes are phrased as "We have done X to improve Y".

We have optimized S3 paging in keep-web to improve performance when it lists directories with more than 1,000 items. #20798

This buries the benefit, which is "improved performance".

I like to put the benefit in the front:

Improved performance of paging in the S3 API of keep-web when listing directories with more than 1,000 items. #20726

Fixed a bug in Workbench 2 where breadcrumbs did not render when parent project information was not available from the left-hand navigation menu. [#19991](https://dev.arvados.org/issues/19991)

Admittedly this is in a section called "Bug fixes and enhancements" but you have six lines in a row that all start with "Fixed a bug..."

I like to lead with the new (correct) behavior instead of describing the broken behavior and saying it was "fixed".

Breadcrumbs now correctly render even when the parent project is not visible in the left-hand navigation menu. [#19991](https://dev.arvados.org/issues/19991)

release-notes-2.7.0 @ commit:70fa8da7d7d50ea73f1c0d69b4a64fe4f41e40fe

back to you

Peter Amstutz wrote in #note-9:

A couple of style/voice/tone suggestions for the future (this is intended to be constructive criticism):

If we want stuff like release notes and similar documentation to have a consistent tone and structure regardless of who the individual author is, typically the way organizations manage that is by having a house style guide, basically the equivalent of coding guidelines for prose. Should we go ahead and start a page on the wiki with these points? It doesn't have to start comprehensive, we can add to it as we think of things.

In general, people don't care what we did, they care about the ways that the software has changed, and more specifically, the benefits resulting from the changes in the release.

For example, some notes are phrased as "We have done X to improve Y".

We have optimized S3 paging in keep-web to improve performance when it lists directories with more than 1,000 items. #20798

This buries the benefit, which is "improved performance".

I like to put the benefit in the front:

Improved performance of paging in the S3 API of keep-web when listing directories with more than 1,000 items. #20726

So I agree the fact that "we" made the change is not the important part, and I'm fine making sure the benefit comes as early as possible. But my concern about this example is it's not a complete sentence: there's no subject. I think the passive voice leads to some awkward construction in more complicated notes, and starts sounding robotic over the course of the whole document. Any objection to "We improved performance of paging in the S3 API…"?

Brett Smith wrote in #note-11:

Improved performance of paging in the S3 API of keep-web when listing directories with more than 1,000 items. #20726

So I agree the fact that "we" made the change is not the important part, and I'm fine making sure the benefit comes as early as possible. But my concern about this example is it's not a complete sentence: there's no subject. I think the passive voice leads to some awkward construction in more complicated notes, and starts sounding robotic over the course of the whole document. Any objection to "We improved performance of paging in the S3 API…"?

So, this is still passive but I think it's a complete sentence:

The performance of keep-web paging with the S3 API is improved when listing directories with more than 1,000 items. #20726

My goal with the sentence construction is to help someone who is skimming quickly to identify changes they are interested in. While we don't want to make the sentences awkward (if it reduces comprehensibility, that's clearly bad) but sounding robotic is a feature not a bug.

(also there's a choice between "is improved", "has improved" or "was improved" and the reason I prefer present tense is because it is describing the present state of the software as compared to the previous state).

2.7.0~rc5-1

arvados|7d974e3dc14efa8c05f1a02fa6ee7be37ee2b8a6
arvados-workbench2|6f8dcb2b13f3058db656908fb26b09e23b527f08

build-and-publish-rc-packages: #202
workbench2-build-release-candidate-package: #131
docker-jobs-image-release: #62

Edit for packer singularity build fix: arvados|1cc3a7c037077e3d64fda794e239c0096b3f033c

packer-build-compute-image: #237

https://workbench2.pirca.arvadosapi.com/projects/pirca-j7d0g-3yslv3eoq94x1uy

Live logs isn't working, browser network tab says "blocked", I think this might be CORS related?

2.7.0-1

arvados|101971b92790b8461ac4c3387014fe70cb7787e5
arvados-workbench2|6f8dcb2b13f3058db656908fb26b09e23b527f08

build-and-publish-rc-packages: #203
workbench2-build-release-candidate-package: #132

docker-jobs-image-release: #63

build-publish-packages-testing-rocky8: #3

build-publish-packages-python-ruby: #78
build-package-r: #26
build-java-sdk: #45

publish-packages-to-stable-repo: #268 (.deb)
publish-packages-to-stable-repo: #274 (.rpm)

build-and-release-docker-arvbox-demo-image: #55

2.7-developer-run-tests: #4