Versions Compared

Old Version 7

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Grazia Quercia

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: attendee: Grazia didn't participate

...

...

  • 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