[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: |
|
||||||||
| 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
Current Process
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
Related
|
| 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 ] |
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:
The next steps are for a module releaser to issue a bug fix release UI Users 2.15.1 (as per
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 ] |
|
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 ] |
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
|
| 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 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. |