Thanks to everyone who gave there feedback in the Redmine discussion and also privately over the last few weeks. We’re ready now to move forward, and here’s the plan:
week 1
Create custom fields for the “Team Backlog” data, multivalued with entries like “Brad’s Backlog”, “Eric’s Backlog” and so on.
Migrate existing backlog issues to the new field
Hide the Target Version field via a plugin (this is a temporary measure, it will return)
Wait a week to ensure team leads are happy with new fields
week 2
Clean up old versions from Redmine
create missing versions for foreman releases
create found in / fixed in custom fields
migrate release information from the Backlogs::Releases fields
disable Backlogs plugin (don’t remove the data though, can be reinstated)
re-enable Target Version field
week 3
commence upgrade path to Redmine 3.x
Note that in week 1 we hide the Target Version field so that users are forced to the new workflow using the backlog custom field - this is so that we don’t get new backlog versions being created after the migration to the custom field has been done. We don’t need the field for actual release data until after Backlogs is removed, so it can be hidden for a while.
Everything is revertible for the first week, since nothing is deleted, so please do test the custom field and ensure that it’s what you need. My understanding is that all that is needed is a place to search by “issues in someone’s backlog”, and we’ll have that.
I’d like to get someone to pair with me while we roll this out - @ekohl@ehelms I guess you would be the obvious choices, but I’ll take any volunteers :). Current plan is to do phase 1 of this tomorrow afternoon my time (July 3, 2018 8:00 PM (Asia: Calcutta), July 3, 2018 10:30 AM (America: New York), July 3, 2018 2:30 PM ( Europe: Prague), July 3, 2018 4:30 PM (Europe: Paris), July 3, 2018 5:30 PM (Asia: Tel Aviv) )
As a side note, obviously expect weirdness and brokeness during these migrations - it’s unavoidable. I’m always open to hearing about something that’s broken for your workflow, and figuring out how to get you unblocked, so reach out to me if that happens.
Final note on API / tooling. I have a plugin written on the side which extends the Version page with information about the Found-in / Fixed-in custom field lists, so that we can filter in various ways. That plugin can also have API endpoints added easily enough, but we’ll obviously have to update the tooling to match. This is part of the “phase 2” section.
Phase 1 is now rolled out - you should find that the Target Version field is now missing from the Edit and Show pages on any issue (admins can still see/set it). However, it can still be used for searches if need be.
I’ve created the Team Backlog custom field, and copied the existing backlogs to it. Target Version remains untouched for now, so you can see the same data in both places. For example:
I have copied over all the data from the backlog versions, but not the open sprint / iteration versions. I can create a custom field for this if it is required (I guess a free-text box will do?).
I will leave it like this until at least early next week before going further - please get in touch if your workflow is broken in some way and we will work to resolve it.
In the above screenshot you’ll also note that I’ve made the Triaged flag available across the whole of Redmine. This seems a useful flag to many of us, and will default to “No” if you just want to ignore it for your project.
I’m starting work on phase 2 today. Current plan is:
Make “Found in Release” a multivalued list
Create “Fixed in Release” as multivalued list
Migrate Target Version string to a backup Custom Field (This field will only be visible to Admins/Moderators to reduce spam, it’s just in case we need to reference that data in the near future)
Clean up old Versions
Create missing Versions
Migrate Release info to Target Version
At this point the Release field will be generally unused, I think - @ekohl / @ehelms does PRProcessor use that at all on a daily basis? I know about the mass-update stuff after a release, but the daily stuff just sets the PR link right?
This is in progress, however I am running out of time for today:
The new fields are live and usable (with caveat, see below)
The Target Version is un-hidden and usable (same caveat, see below)
Backlogs is disabled (different caveat, see below)
Much cleanup to do
Caveat 1 - Target Version
The fields are usable but I haven’t yet created all the missing Versions need to migrate the Release data. As such, you will see misleading info in Target Version until at least tomorrow. Feel free to create new Versions for open releases of projects so that they feature in all 3 fields, but please don’t mess with the Target Version for existing issues right now.
Caveat 2 - Backlogs
Backlogs is removed but the fields still exist in the DB, along with their constraints. I don’t want to drop those columns/tables just yet, so if you see weirdness, let me know. We have already fixed one issue that prevented issue creation . This is a temporary measure until I have migrated all the data.
Due to a stupid bug in my script, pretty much all of the 12000 bugs were assigned to version 1.3.1. This is a historical issue, and shouldn’t affect operations right now. I will get the data fixed up from the backup later today & tomorrow.
Target Version now reflects what used to be in Release
Old Target Version data has been saved to a custom field for history
All the old “Iteration/Sprint/Backlog” versions have been deleted
Leftover issues have largely had their Target Version unset (a few went to appropriate project Backlogs)
Custom fields exist for Found-in and Fixed-in
This works with version sharing into a subproject, eg:
(This is from the Salt plugin, 10.1.0 and 11.0.0 are Salt plugin Versions)
You may see issues cropping up in odd places for a while thanks to the removal of the old mis-used Versions, so allow extra time at your next planning. You can search on “Old Target Version” field if you really need to.
There’s an open question for @katello: do you want the same found-in / fixed-in fields? I can make them project wide if people want them (and migrate the old “Found in Katello release” data to it)
I’d like to reduce the Foreman version spam in plugins too - I was hoping to re-parent Plugins to their own top-level project, but since over 30 of them use Inherit Members, that’s not a good plan. Instead I will set all the Foreman versions to sharing=none, and see if that helps. If you discover a need for sharing a Foreman core version to another project, speak up
Apart from that, I will (mostly) leave Redmine alone for a few days now to let the dust settle, and then I will look at starting the actual upgrade to 3.0+ next week
There was general agreement in IRC to set the Foreman project versions to non-shared. However, in attempting to do this, a flaw was uncovered. Unsharing the version has caused the Target Version to be unset in the subjects (as they can no longer see it), and emails have been sent out about the change (sorry)
This has affected the issues in subprojects (proxy, installer, etc) with these versions
1.2.X
1.18.0
I killed the script at 1.3 so that should be all that’s affected.
Right now you’ll see the target version deleted, eg Issue 24155. This is a mea culpa as I didn’t notice the effect when testing locally.
I have a backup of the DB from this morning, so I can restore the affected versions later today or first thing tomorrow morning. New 1.18.0 versions have been created in the Proxy, Installer and Packaging repos, so feel free to assign issues appropriately if you find any - it won’t affect what I’m restoring.
Sorry for the noise. I’ll work out a cleaner “unsharing” process tomorrow, after I’ve fixed the issues caused.
Foreman top-level versions are now unshared with subprojects. In order to achieve this with minimal spam, I scripted the Rails console to create matching versions (where needed) in subprojects, and reassign issues to the new versions.
This has been successful (1195 bugs were updated), and here’s an example from the Smart Proxy page:
Note how they don’t say “Foreman - 1.11.2” any more, these versions are for this project alone.
This means the Target Version / Found-in / Fixed-in fields now only show the subproject versions, for example try editing a Katello bug and you’ll see there’s only Katello versions in there.
However, in a handful of edge cases, bugs in subprojects were assigned to top-level versions, which means some subprojects gained versions that don’t match they usual scheme (e.g. Katello now has a 1.16.0). For completeness, here’s the list of Projects that had at least one Version created - project owners may wish to investigate:
Sorry again for the mess earlier this week, this should resolve it. I will also go and migrate the “Found in Katello Release” custom field to the new “Found In” field, for consistency
I am reviewing Versions for Discovery, thanks a lot for taking a look on this.
Would you mind creating a wiki, post or page of any kind with recommended issue process? Because with new flags it can be now confusing what to use for what. I want to follow core process for discovery, but I tend to forget things (like everyday things in my life…) so I would love to have such a page.
The Git repos weren’t imported in the Redmine database anymore. This caused issues not to be closed anymore. I’ve just ran it manually so some of you may have been some notifications. There’s a PR open for the fix:
. This is a temporary measure until I have migrated all the data.
). Here’s an example:
