[FOLIO-2478] Release mod-inventory for Q1 2020 Created: 26/Feb/20 Updated: 03/Jun/20 Resolved: 14/Apr/20 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Story | Priority: | P2 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Marc Johnson |
| Resolution: | Done | Votes: | 0 |
| Labels: | release | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Core: F - Sprint 85, Core: F - Sprint 86, Core: F - Sprint 84 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Story Points: | 5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Prokopovych | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comments |
| Comment by Ann-Marie Breaux (Inactive) [ 02/Mar/20 ] |
|
HI Marc Johnson I added
|
| Comment by Marc Johnson [ 03/Mar/20 ] |
|
Thanks Ann-Marie Breaux
I think that it might be worth me preparing the releases for mod-inventory-storage and mod-inventory early, prior to any of these outstanding changes going in. Then doing a subsequent release when those changes are in. That way, the 2020 Q1 release isn't blocked by them, neither is it affected by partial functionality. Rather than this second release being a bug / hot fix release, I suggest we do what we have done in the past for changes that will pass the release deadline, and stop other changes being made to the mainline code until these are ready and do a regular release. During a conversation with Cate Boerema yesterday, and recent triaged hot fixes, it became clear to me that I have a different understanding of what constitutes a bug / hot fix release. Hence, I will wait for advice from the release triage group before actioning any of this. Cate Boerema Jakub Skoczen Mark Veksler Anton Emelianov Mike Gorrell What do you think? (If I've missed folks from that group, please include them) |
| Comment by Cate Boerema (Inactive) [ 03/Mar/20 ] |
|
Hi Marc Johnson. Here is the way I have been using the terms:
Hopefully that's generally aligned with how others think about this. Jump in if not. From my perspective, your plan here is a good one, Marc Johnson. Even though the follow-on MODINV releases will be atypical bugfix releases in that they are not for fixing bugs and they are not patch releases, I think they should follow the same process as any other bugfix release (i.e. they need approval from the #release_bug_triage group) |
| Comment by Ann-Marie Breaux (Inactive) [ 03/Mar/20 ] |
|
Hi Marc Johnson and Cate Boerema I'm fine with that. It's definitely functionality we need to get into Q1, so I don't want it to get lost. Would it make sense to create a Q1 follow-on release story and re-link these issues to it? Cate Boerema can I get pre-approval from the release_bug_triage group for these? Without them we cannot finish the work to be able to create instances, holdings, and items in Inventory with proper import mappings. |
| Comment by Ann-Marie Breaux (Inactive) [ 03/Mar/20 ] |
|
Also a quick question about preceding/succeeding - yesterday Charlotte Whitt mentioned several stories that she was hoping would be finished in Q1, but I only see one linked here. Are there others that should be linked as blockers? |
| Comment by Charlotte Whitt [ 03/Mar/20 ] |
|
Ann-Marie Breaux - I have updated
|
| Comment by Ann-Marie Breaux (Inactive) [ 03/Mar/20 ] |
|
Perfect - thank you Charlotte Whitt! |
| Comment by Marc Johnson [ 19/Mar/20 ] |
|
Cate Boerema Ann-Marie Breaux Mark Veksler Anton Emelianov Jakub Skoczen To confirm, we are applying an exemption to the quarterly release deadline for mod-inventory in order to allow FoliJet to complete the ongoing changes to mod-inventory? Whilst that is ongoing, I should limit the merged changes to mod-inventory to only bug fixes we intend to get into 2020 Q1, so that a new mainline release, 14.1.0 or 15.0.0 can be performed when ready. Is my understanding of the current situation correct? |
| Comment by Cate Boerema (Inactive) [ 19/Mar/20 ] |
|
That sounds right to me, Marc Johnson |
| Comment by Marc Johnson [ 21/Mar/20 ] |
|
As per our discussion on
|
| Comment by Kateryna Senchenko [ 27/Mar/20 ] |
|
Hi Marc Johnson, I merged the PR for updating data-import-processing-core dependency in mod-inventory (
|
| Comment by Ann-Marie Breaux (Inactive) [ 27/Mar/20 ] |
|
Yayyy!!!! Thanks Kateryna Senchenko and thanks Marc Johnson!! |
| Comment by Marc Johnson [ 28/Mar/20 ] |
|
mod-inventory 14.1.0 has been released which includes the data import work for 2020 Q1. |
| Comment by Ann-Marie Breaux (Inactive) [ 06/Apr/20 ] |
|
Hi Marc Johnson This was released, per your comment above - right? OK to close it? Might it be helpful to have these in the appropriate projects (e.g. mod-inv) instead of FOLIO? Would that make it easier to keep track of them on team boards? Or maybe FOLIO project tickets show on your team board anyway. |
| Comment by Marc Johnson [ 08/Apr/20 ] |
mod-inventory has been released multiple times. I've been either keeping these issues open if I expect another release or re-opening them when a new release is needed, as my interpretation of these issues was to track releases during the 2020 Q1 release process.
I don't know. The creation of them was suggested by and done by Cate Boerema because other teams had used release issues. I don't know if it was intended that they get moved to the individual projects. A challenge with them being in the module projects themselves (a bit like with spikes) is that they confuse the release and version management because they don't have fix versions.
As I understand it, the Core Functional board uses the team field in JIRA and so can include issues from any project. Cate Boerema did raise a question about how I have been using these issues. Maybe for next quarter, the project can establish a standard process across teams for these kinds of issues e.g. when they should be closed, what project they should be in, etc. Could that be a topic for the retrospective? |
| Comment by Ann-Marie Breaux (Inactive) [ 08/Apr/20 ] |
|
Hi Marc Johnson Interesting! At least on Folijet (not sure about other teams), we do a new task for each release, in the project that will be released, and tag that task with the release number. Then for any stories/bugs that need finishing before the release, we link them as blockers. That way when all the blockers are done, we know we can make the release. Here's an example:
I can see how you would need to manage it differently if using the same Jira for multiple releases of the same module over the course of a quarter. No worries! |
| Comment by Marc Johnson [ 08/Apr/20 ] |
At a quick count, that means FoliJet has raised at least 16 separate issues to manage the release work for the 2020 Q1 release period alone. Was that the case? We could raise new release issues for every release. As an example, that would mean that, for only the modules I am the lead maintainer of, there would need to have been at least 16 issues as well. One of the challenges that we've faced on the Core Functional team, is that because multiple teams work on the modules, it is hard to keep the list of blockers up to date, even on the initial release. My concern with this approach is that it could be significantly more admin. |
| Comment by Ann-Marie Breaux (Inactive) [ 08/Apr/20 ] |
|
27 since 1 January (https://folio-org.atlassian.net/issues/?jql=text%20~%20release%20AND%20%22Development%20Team%22%20%3D%20Folijet%20AND%20updatedDate%20%3E%3D%20startOfYear()%20AND%20issuetype%20%3D%20task%20ORDER%20BY%20updated%20DESC%2C%20key%20ASC - there's 3 false hits in the list) It helps us stay organized and track stuff. I can definitely see how it gets tricky when working with lots of POs, plus issues coming at you from other teams. But absolutely no worries - when it comes to the MOD/UI Inventory stuff, we're happy to follow whatever Jira structure Core-fxn decides on. |
| Comment by Ann-Marie Breaux (Inactive) [ 08/Apr/20 ] |
|
FWIW, Thunderjet had 51 since 1 January (https://folio-org.atlassian.net/issues/?jql=%20Summary%20~%20release%20AND%20%22Development%20Team%22%20%3D%20Thunderjet%20AND%20updatedDate%20%3E%3D%20startOfYear()%20ORDER%20BY%20updated%20DESC%2C%20key%20ASC - 3 false hits in the list). They are using stories for their release issues, whereas Folijet uses tasks. I think they're the team that comes closest to Core-fxn in terms of the numbers of modules they are managing. |