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")
Deadline is TBD for both 8.2 and 7.6.4. 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?
Please feel free to take part in it; there is a test plan; please create bug tickets for anything that isn't working
Testathon test plan is heavily front-end centered, developers can assist with testing things that are back-end
This two week period is also a good time to start the translation process for 9.0, as we are feature complete
Question: Is there a list of what is newly created parameters in the English file in DSpace 9?
There is a script that marks new keys that need to be updated; Art will create PR for this script: npm run sync-i18n; can be included in release candidate run for next release
There a number of test cases that are hard to test (T157, T158, T162, etc.)
If anyone has instructions on how to test these, please write them down and share them
DSpace-CRIS & DSpace Potential Merger
There is a new wiki page documenting the differences between DSpace-CRIS and DSpace (both architectural differences and feature differences)
Please enhance this page if you know of any other differences that are currently not listed
Testathon Check-in
Reminder about Feature Documentation; we have a good number of features in our release notes that are not documented yet
Please link to documentation in PR that's created
Anything that's not been documented does not get tested in Testathon
Some bugs have already been fixed (e.g. SSR stuff)
Look for the testathon label in GitHub to find Testathon-created bugs
Bug fix PR creation deadline is May 2; Due date for merging bug fixes is May 16
Went through a number of bug tickets
#4141: Long bitstreams get cut off at the end of the page; Art volunteered