For the next few weeks, our DSpace Developer meetings will be cancelled to allow everyone time off to celebrate holidays and the New Year. Our next Developer meeting will be on Thursday, January 9, 2025.
New Feature Development Deadlines
Feature PR Creation Deadline: Friday, February 21, 2025
Feature PR Review/Test Deadline: Friday, March 14
Feature PR Merge Deadline: Friday, March 28
9.0 Release Candidate: Friday, April 4
9.0 Testathon: April 7-18 (two weeks)
9.0 Translation updates: April 7-18 (during Testathon)
Bug Fix Deadlines
Bug Fix PR Creation Deadline: Friday, May 2
Bug Fix PR Merge Deadline: Friday, May 16
Documentation & Release Week: May 19-23
9.0 Release Announced: Monday, May 26, 2025
Agenda
Discussion Topics - If you have a topic you'd like to have added to the agenda, please just add it.
Commit structure guidelines for PRs? - small question / idea by Kim S
I wondered if we should have some soft rules for e.g. rebasing/squashing PRs when the commit list gets too long (especially if half of them are just "fix imports", "fix lint", etc - which I am very guilty of!), and asking that PRs not contain merge commits so they are easier to port around and cherry-pick. I feel like this would make our git tree easier to read and use. I'm also aware that requiring squashing or interactive rebases might make it hard for reviewers to follow though since it might not be clear if the reviewed changes are the same..
Board Review:
9.0 Project Board- Review PRs collaboratively or Assign new PRs to volunteers to code review and/or test.
Backlog Board- Are there any tickets here stuck in the "Triage" column? We'd like to keep this column as small as possible.
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?
If anyone wants to help test, code review or claim any of these, please feel free to do so
Other topics - Commit structure guidelines for PRs?
Should we have soft rules for rebasing/squashing PRs when the commit list gets too long?
For committers, there is the functionality to "squash and merge" under "Merge PR"
Alternatively, we could offer training how developers can squash their own commits
This discussion needs to be continued (also within the Committers group); Kim Shepherd will start a discussion on the mailing list
Board Review
A lot of PRs in the "Reviewer Approved" section were tested - thank you; Tim will work through this list and merge as quickly as possible; if anything seems missing (such as tests), Tim will message you
Went through and reviewed PRs in the "Needs Reviewer Assigned" column
#3256: need feedback on this first before getting into a formal review; please try this out and test it and provide feedback if possible