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?
Q: Where is the map generated? A: in a folder with one file for each decorator
Giuseppe assigned to decorators PR, Tim will take a look at this as well
Giuseppe will review Alex's PR and provide feedback
He will let Tim know if he wants to give an update in an upcoming dev meeting
Want to try to get these two merged relatively quickly, need to think about which one to merge first
May make sense to merge the decorators PR first, as it's smaller. But, Giuseppe will take a look at it to see if it can easily be worked into the NX PR.
Discussing how the NX PR is structured
Art notes we may want to consider using the default "libs" directory that NX uses. Currently, the PR renames this folder to "modules". Recommends we name "modules" back to "libs"
The current PR is just the first phase. This is where we is split parts of DSpace into libraries (in "modules" folder). Currently just two libraries "core" and "shared/utils". Everything else is still in the "src/app" directory.
Future Goal is to get the "src/app" folder as lean/empty as possible. It should be possible for institutions to use the "src/app" folder for only the code they want to override . This would let the "src/app" directory work similar to the Maven overlays that were used in DSpace 6 (and below) – "src/app" would let you overlay/override any defaults in the "modules" folder.
The main question is how to get to that goal. This PR is just the first phase.
2nd phase could be to move everything out of the "src/app" folder immediately into a single massive module. Then 3rd phase would be to break that massive module apart into many different small modules
Or, 2nd phase could be to move things out of "src/app" folder little-by-little, into separate modules. The goal would still be to get everything out of "src/app", but we'd just do it module by module.
For anyone interested to check out how NX works, create a new NX app and play around with it
There is a wiki page that discusses the NX proposal (as to why to even look at NX)
Other topics
Question for Angular experts: can we explain more about the transferState configuration in PR 3953?
State refers to NGRX state – before this PR, after server-side rendering, we would transfer state from server to client (through piece of JSON) to avoid having the client need to make the same requests already made by the server.
Q: Is there a situation where we want to set transferState to false? A: 4Science sets it to false in their production instances.
It might be useful to document better when to set this to false (and give a reason why)
Currently this configurate seems to exist just because there are scenarios where you might want to set transferState to false...but most may want to keep it as true.
If anyone interested in discussing test configuration, there is an issue open to clean all of this up