owned this note   changed 4 years ago  
Published Linked with GitHub

Github Issues Migration Plan

There are overall two areas

  1. The figuring out of our processes
  2. The actual migration of data

The Processes

Bugzilla

Downstream already links to Github Issues

Upstream

Port the Redmine Bugzilla script (which already runs on GHA) to be for GHA and

JIRA

We don't have any integration today. Other folks are working on adding JIRA <-> GHI integration so that can help out with this portion later.

We should be able to rely on Satellite bugzilla <-> JIRA automation? (rchan suggestion)

For other stakeholders: any future integration is TBD

Epics

Labeling Epics

TBD: Either use [EPIC] in the issue title, or create an Epic label

Identifying sub-issues and parent issues

option 1: In the parent issue description list the issues as clickable links and then child issues would show "a related"
option 2: Use a project board to organize the epic

Issue Relation

Referencing another issue shows a relation

Tags

Common labels use common colors

  • Bugzilla
  • High Priority
  • Low Priority (maybe?)
  • Katello
  • GalaxyNG
  • Documentation
  • Easy Fix
  • Wishlist (maybe?)
  • Triaged
  • Bug
  • Feature
  • Performance (maybe?)
  • Demo-worthy ;)

Example label system (one of the better ones I've seen, skip to page 3-5 for the general ones) https://github.com/servo/servo/labels

We won't have Installer and Operator or CI/CD because they'll have their own GHI projects now

Default labels: https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization

Project Specific labels

  • Pulp2 (for RPM project only)
  • Dev Environment (for installer only)

Private issues and comments

We won't have these

Querying and Filtering

Filter syntax: https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests

We won't have saved queries, but instead we can have a wiki page that will have links on it basically acting as saved queries

Handling the workflow

NEW: Open and no assignee
ASSIGNED: Open with assignee
POST: Open and has linked:pr
MODIFIED: Issue was closed via merge PR with closes #1234
CLOSED - CURRENTRELEASE: Closed and on a milestone

https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests#search-for-linked-issues-and-pull-requests

Indicating a Release Blocker

Add an open issue to the milestone.

Moving Issues between projects

Yes GHI can move issues between projects

Checklist templates

Put these onto a wiki page as escaped markdown content and then paste it into the issue you need it in

Sprint

Have a sprint label for the current sprint
To look at old sprints: have a query that uses sprint start and end dates and look for issues that were closed in that time window
Alternatively we can use a project board especially if we move to kanban

Wiki

Yes we should use the wiki, and let's let each repo decide if they want to use it
We will port this data manually: https://pulp.plan.io/projects/pulp/wiki/

Quarter field and wishlist buckets?

[homework] Experiment with project boards https://github.com/orgs/pulp/projects

The Migration Plan

  • Which issues do we migrate over (all? open?)
    • Only NEW issues
  • Should we keep redmine issues (as readonly)?
    • Keep redmine but make it readonly
    • Changelogs still point to redmine
  • Need to align to a release
  • Backports/old release branches
    • Port release automation to old release branches
  • Move repository by repository
    • Move pulpcore later/last
      • Lots of issues aren't labeled properly
  • Have 1-2 people working with plugins to migrate their issues
  • Unify labels across repositories (see line 45)
    • Needs to happen before issue migration
  • Use existing tooling
  • Status of issues?
    • Add a new status for migrated issues
  • Migrate milestones?
    • Migrate open milestones
  • Make a project checklist
Select a repo