[FOLIO-1503] Where should bug fixes be done first? Created: 17/Sep/18  Updated: 26/Oct/22  Resolved: 26/Oct/22

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Adam Dickmeiss
Resolution: Done Votes: 0
Labels: ci, core, sprint47, sprint48
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1482 update dev.folio.org with information... Closed
Sprint:
Development Team: Core: Platform

 Description   

Goal

Describe the process for making bug fixes. Primarily during the 2018 quarter 3 release. Some changes may remain in place afterwards.

Roles Involved

  • Reporter - the person who reported the bug
  • Developer - the person making the changes required to resolve the bug
  • Manual tester - the person conducting the manual testing of the change
  • Module releaser - the person performing releases of a module

Current Process

  1. Reporter raises a bug (in the appropriate JIRA project)
  2. Product owner prioritises bugs and changes
  3. Developer picks up the bug (when it is the highest priority available work)
  4. Developer issues a pull request to fix
  5. Developer or reviewer merges the pull request
  6. Developer changes status to In Review
  7. Change is deployed to folio-snapshot environment
  8. Change is deployed to folio-snapshot-stable environment (when the regression tests pass)
  9. Manual tester tests the fix and either: Closes the issue if the bug is fixed; re-opens the bug if the fix did not meet expectations or waits if the folio-snapshot-stable environment does not include the fix
  10. Module releaser issues a formal release including the bug fix (probably with other changes)

Intended Changes

In order to apply specific bug fixes (and not other ongoing changes) to a released version of a module, we intend to make those changes to both the currently in development version and selectively for one or more previously released versions.

This change raises some questions (with thanks to Zak Burke for helping formulate these) about the current process.

Questions
In an ideal future, how should:

  • A module releaser know that a bug fix has been tested, so a bug fix release can be made?
  • A module releaser know which bug fixes to include in a bug fix release for a previously released version?
  • A developer know which version a change is intended to be included in?

Related

  • How would we like a tester be able to tell if a change is available to test within the FOLIO snapshot stable environment?
  • The mechanics of releasing bug fix versions (see FOLIO-1482 Closed )


 Comments   
Comment by Marc Johnson [ 17/Sep/18 ]

Zak Burke Mike Taylor Jakub Skoczen Did I miss anything from the scope of this task?

Comment by Marc Johnson [ 19/Sep/18 ]

Mike Taylor Thanks. I did end up getting distracted whilst I was writing this, thank you for the feedback on consistency issues, I think they should be resolved now.

I'm not aware of any environment where we deploy formally released versions on a regular basis. Given the variation in formal release cycles between modules I think any such environment would be highly unstable. I think the quarterly release process is the most closely related activity.

Comment by Marc Johnson [ 19/Sep/18 ]

Mike Taylor That's all good, I want those kinds of things spotted

Comment by Mike Taylor [ 19/Sep/18 ]

I'm not aware of any environment where we deploy formally released versions on a regular basis.

John Malconian Wayne Schneider Isn't that what the old folio-stable used to be?

Comment by Marc Johnson [ 19/Sep/18 ]

I believe the primary question, specifically for the 2018 Q3 releases, that we are trying to answer is:

In an ideal future, how could a module releasor know to release a bug fix version including a specific fix?

Taking a fictitious example, for our current quarterly release:

  • UI Users 2.15.0 is released and deployed to the quarterly release environment
  • A critical bug is discovered that needs to be fixed for the quarterly release (by prioritising and labelling)
  • A fix is applied in the latest version of UI Users 2.16.0 (not released, steps 3..8 above)
  • The bug is tested in the folio-snapshot-stable environment and is resolved as Closed (meaning fixed)

The next steps are for a module releaser to issue a bug fix release UI Users 2.15.1 (as per FOLIO-1482 Closed ) and for this to be deployed and tested in the quarterly release environment.

In an ideal future, what should the trigger for the module releaser be to perform the release of UI Users 2.15.1 containing the fix?

What should happen after the bug fix release has been deployed and tested (e.g. what if it succeeds or fails testing)?

Comment by Mike Taylor [ 19/Sep/18 ]

Also: do we envisage fixing the bug in 2.16.0 and cherry-picking into 2.15.1, or vice versa? Or can we leave that to the developer's discretion?

Comment by Marc Johnson [ 19/Sep/18 ]

Mike Taylor

I believe the intent is that critical bugs are to be fixed in both places. I think they could be applied in either order.

The sequence I described of applying it to master first is based upon the assumption (from Monday's conversations) that the fix is to tested in folio-snapshot-stable prior to the fix being applied in the quarterly release environment (it might be that was based upon perceived ease or expediency).

If that assumption does not hold, the question about the bug fix release trigger changes fundamentally (as the bug fix release would need to happen prior to the testing), and hence the sequence in my example would also change sufficiently.

Does that make sense?

Comment by Mike Taylor [ 19/Sep/18 ]

The sequence I described of applying it to master first is based upon the assumption (from Monday's conversations) that the fix is to tested in folio-snapshot-stable prior to the fix being applied in the quarterly release environment

Yes, of course – makes perfect sense.

Comment by Zak Burke [ 19/Sep/18 ]

We should try to avoid git cherry-pick if possible; it makes a mess of the history. A better approach would be to branch from the commit where the release-branch and master split (call it fix-branch), commit the fix, and then merge fix-branch into both master and release-branch. It's quite possible those merges will be very different, especially if master has moved far ahead of release-branch. On the one hand, yes, of course we want to test a fix thoroughly before merging it onto a release branch. On the other, testing how a fix works on a different branch does not accomplish that.

Comment by Marc Johnson [ 19/Sep/18 ]

Zak Burke Good points. There is risk that the bug fix doesn't work in one of the versions. Effectively I think this means it needs testing twice.

Could you also post the cherry-pick aspects to FOLIO-1482 Closed about the release mechanics themselves.

Comment by Mike Taylor [ 19/Sep/18 ]

I am surprised to read Zak Burke's comments. To me, `git cherry-pick` seems exactly right: it conveys semantically that we are applying the same fix in two branches. (Though the merge-into-two-different-branches approach does have a certain elegance.)

Comment by Zak Burke [ 19/Sep/18 ]

The issue with cherry-pick is that when the commit pasted ("picked", whatever) onto the new branch, its parent is set to the HEAD of that new branch, disconnecting it from the commit on the original branch. So, rather than conveying that we are applying the same commit in two places, in fact we lose the fact that the two commits are linked.

Full disclosure: I'm no git expert. My comments are largely based on http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html and a bit of other recent reading when Michal Kuklis and I were trying to figure out the best way to manage some changes we wanted on the Q3 and master branches. As to the author's claim that git flow solves everything ... I'm not sure. git flow has long felt like an over-engineered solution to me, but reading about it again, especially in the context of long-lived release- and bug-fix-branches, it feels surprisingly compelling.

Comment by Michal Kuklis [ 19/Sep/18 ]

I think there are two different ways to handle it depending on the workflow we choose:

a) use cherry-pick / rebase workflow
b) merge workflow

Here are nice and short steps for two of them (where develop = master and release = q3 in our case):

https://gist.github.com/wildlyinaccurate/daec7910958330a64754

I think what Zak Burke is proposing here is b)

Comment by Mike Taylor [ 19/Sep/18 ]

rebase always makes me queasy.

Comment by Michal Kuklis [ 19/Sep/18 ]

Ah sorry Marc Johnson I thought this is the appropriate place for this

Comment by Adam Dickmeiss [ 26/Oct/22 ]

If a bug fix is a general bug fix going forward and is compatible with a release, by default bug fixes should go into master. This makes it possible to test that the fix does not break things further, only being used in snapshot environments first. If all is well, it can be cherry-picked to a release branch (typically with prefix b). Yes, that means rebase or rewrite, but that's the best option.

If the bug fix is only relevant to a release and is trivial and the fix does not make sense to apply on master, for example if master already is using a different solution entirely, then it's appropriate to fix only in the release branch.

The above is inline with the release procedures.

Generated at Thu Feb 08 23:13:49 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.