Discussion/proposal around refactoring and simplifying Live Import and External Data frameworks: https://github.com/DSpace/DSpace/issues/9758 (nothing concrete yet but would be great to get thoughts added to this issue and maybe find some collaborators)
To quickly find PRs assigned to you for review, visit https://github.com/pulls/review-requested (This is also available in the GitHub header under "Pull Requests → Review Requests")
Early brainstorms at DSpace Release 9.0 Status. Please feel free to add your own brainstorms or link in tickets that you wish to be considered.
Goals for 8.1 / 7.6.3
Deadline is TBD for both 8.1 and 7.6.3. Bug fix releases do not have fixed/scheduled deadlines.Instead, the developer team will determine when to create a release based on the significance of the issues to solve. (e.g. If major issues are fixed, then a bug fix release will occur more rapidly. If minor issues are found, then a bug fix release may be delayed until sufficient fixes have been made to warrant a release)
Bug/security fixes only. These minor releases will not include any new features.
New "themeable components" (for dspace-angular) are allowed in bug fix releases, provided that they don't significantly modify component behavior or similar.
Accessibility fixes are also allowed in bug fix releases, provided they don't significantly modify component behavior or similar.
Bug fix PRsshould be created against "main" branch where possible. The "main" branch has the most strict code style rules. (i.e. PRs created against dspace-7_x are becoming more difficult to port forward.)
Per our support policy, bug fixes are only guaranteed to be ported back to 8.x. That said, where possible, we'll try to backport bug fixes (especially significant ones) to 7.6.x.
Keep in mind, if a specific bug fix is important to you in 7.6.x, then it is best to create two PRs (one for main and one for "dspace-7_x"). If you are able to provide a backport version of the PR, then we will merge it alongside the "main" branch version.
NOTE: In many scenarios, a backport to "dspace-8_x" should be possible to automate using the "port to [branch]" labels & the "Port merged Pull Request" GitHub Action
Try "Pull Request Trading" for a quicker review
Do you have a PR stuck in "under review" that you really want to see move forward? Or maybe it's someone else's PR but you want to get it more attention?
We have been removed from open-source access to DockerHub.
Tim has reapplied, we are waiting for a response from DockerHub
This has impacted Tim's work in terms of testing and merging
We can currently merge only 2-4 PRs / day. After that we are blocked & we can no longer push images to DockerHub.
This can also negatively impact Angular e2e tests because they rely on those DockerHub images. If we hit the rate limit while pushing images to DockerHub, then the images in DockerHub may end up in an unexpected state. In some cases, this has caused e2e tests to fail because they cannot download the expected image from DockerHub.
Once we hit this rate limit, we are blocked entirely for up to 6 hours. No Docker images can be pushed to DockerHub.
Tim has worked on a solution to become less dependent on DockerHub by building Docker images against the GitHub Container Registry to avoid hitting rate limits in DockerHub. We then copy the built image to DockerHub in a single command, which decreases the number of requests we make to DockerHub.
Question from Kim: do we need to copy every single build over to DockerHub or only main images (for releases)?
Not necessarily, if we use the GitHub container registry, we may not need to push as much to DockerHub as we used to
For example: We may be able to exclude pushing test images (e.g. "dspace-test") to DockerHub, or even just push release images (dspace-8.0, dspace-7.6.2, etc)
Question: are there valid alternatives to DockerHub?
Yes, Google, Amazon, others have them, but they are not free; DockerHub seems to be the main registry used by open-source
If anyone has knowledge of a viable alternative, please let Tim know
Pascal researched the Google registry, but their free plan does not work within the capacity load we need
Tim is working on an additional PR to move the build process to using GitHub Container Registry which builds off of #10080. This will hopefully be coming later today or Monday.