Page History
...
- (40 mins) Discussion Topics - If you have a topic you'd like to have added to the agenda, please just add it.
- 7.6.x release topics - bug-fixes only.
- Development process reminder
- Two development branches:
dspace-7_x
andmain
& new "port to 7.x" and "port to main" labels - Two project boards in GitHub: DSpace 7.6.x Maintenance and DSpace 8.0 Release
- Two development branches:
- Development process reminder
- 8.0 release topics
- Anything new to discuss?
- Stale issues/PRs in GitHub
- v6.x is now EOL. Tim will be closing all old issues/PRs related to 6.x (and 5.x if any still open). These are all obsolete.
- Should we consider enabling Github's "stale" action, which will auto-warn if a PR/issue is "stale" and then auto-close it if no further activity occurs?
- E.g. We could flag s as "stale" after 1-2 years. Then automatically "close" if no more activity for an additional 2 weeks to 1 month?
- PRs - Flag as "stale" for 2 years. Close after 1 month.
- Issues - Flag as "stale" after 1 year. Configure message to ask to reproduce again. Close after 2 months.
- (No Updates) Demo Site migration to Lyrasis (https://demo7.dspace.org/ and https://api7.dspace.org/server/)
- Tim will work with Lyrasis to make this happen as soon as reasonably possible now that 7.6 is released.
- Demo site will be renamed back to "demo.dspace.org" (instead of "demo7.dspace.org").
- Old 6.x demo site: Should we keep it around temporarily at "demo6.dspace.org"? Or just shut it down?
- (Other topics?)
- 7.6.x release topics - bug-fixes only.
- (20 mins) Board Review & assignments:
- Backlog Board - Are there any tickets here stuck in the "Triage" column? We'd like to keep this column as small as possible.
- 7.6.1 Project Board - Assign new PRs to volunteers to code review and/or test.
- 8.0 Project Board - Assign new PRs to volunteers to code review and/or test.
...
- Tim Donohue
- Paulo Graça
- Mark H. Wood Grazia Quercia (4Science)
- Corrado Lombardi (4Science)
- Julian Timal (eScire)
- Martin Walk
- Melissa Anez
...
- Bug/security fixes only. Release will occur when sufficient fixes have been made to warrant a release.
- Fixes MUST be applied to the "dspace-7_x" maintenance branch (for either backend or frontend)
- Fixes MUST be either cherry-picked to "main" branch (for 8.0) or copied into a PR against "main".
Notes
- Stale issues/PRs in GitHub
- v6.x is now EOL. Tim will be closing all old issues/PRs related to 6.x (and 5.x if any still open). These are all obsolete.
- Regarding the GitHub "stale" action.
- Lots of good discussion. Concerns expressed about annoying developers. While we want to remind developers/ourselves when issues or PRs are "stale" or old, we want to avoid being annoying or closing anything without any explanation.
- Decided to try two different rules for PRs vs Issues:
- PRs - Flag as "stale" for 2 years. Close after 1 month. (Goal is to close PRs which are likely now obsolete – after two years, they've missed two releases. Either update the PR or we close it)
- Issues - Flag as "stale" after 1 year. Configure message to ask to reproduce again. Close after 2 months. (Goal is to auto-revisit any Issue that has been overlooked for one year. If it's a bug, ask if the developer can reproduce it on the latest version of DSpace. Close if no response/updates)
- We will configure nicer messages for the "stale" warning to make it clear we need to revisit this older work.
- Tim will notify developers on Slack & dspace-devel before implementing this. The initial run of this action may catch a lot . We don't want to annoy everyone, so we should pre-warn them.
- While visiting Boards, we revisited discussion of the 7.x maintenance.
- How do we deal with bug fixes & applying them to both 7.x and 8.0
- Do we require them all to be applied to a single branch (either dspace-7_x or main)? Seems like that may be hard as it could require a developer wanting to submit a small fix to get familiar with unfamiliar code
- Do we apply everything to "dspace-7_x" and then merge the "dspace-7_x" branch into "main" to sync up changes in bulk? Concerns that waiting too long will let these branches diverge. Fixes applied to 7.x may be needed on main. We want these branches to hopefully be "in sync" at all times.
- Can we require multiple PRs? One against "dspace-7_x" and one against "main"
- This is a lot of work for developers, but it may be necessary for larger fixes to ensure they can be easily applied to both changes.
- Smaller fixes could be an exception to the rule (similar to our "1 Approval" exception to 2-person code review rule for smaller PRs). They can be applied to either branch & Tim will cherry-pick or create a small PR to fix on other branch.
- Tim will add these notes to our "Goals for 7.6.1" section in next weeks agenda. DONE: 2023-07-13 DSpace Developers Meeting#20230713DSpaceDevelopersMeeting-Goalsfor7.6.1
Overview
Content Tools