GitHub issues for core components #390
Conversation
| - link:https://github.com/users/timja/projects/4[Core maintainers attention] | ||
| - link:https://github.com/users/timja/projects/3[User experience project] | ||
|
|
||
| Issues need to be added to a project this can be achieved with a script link:add-issue-to-project.sh[]. |
There was a problem hiding this comment.
It also can be done via GHA like https://github.com/actions/add-to-project
There was a problem hiding this comment.
That doesn't work during import, actions don't get triggered.
I do have an action here that I've used to test that it works after migration is complete:
https://github.com/timja/jenkins-gh-issues-poc/blob/master/.github/workflows/main.yml
|
|
||
| ==== Dashboards | ||
|
|
||
| A number of Jira dashboards are setup. |
There was a problem hiding this comment.
I don't know if it's the case for Jira, but on GitHub everyone can create its own project(s).
There was a problem hiding this comment.
It is, although it's more complex on Jira, you need to share the dashboard (with the right group) and you need to share the saved query.
| ==== Cannot mark one GitHub issue as caused by or depending on another GitHub issue | ||
|
|
||
| Jira allows explicit relationships to be set on links. | ||
| GitHub requires you to type 'Caused by' and 'Depends on' yourself. |
There was a problem hiding this comment.
There is a GHA for this: https://github.com/marketplace/actions/dependent-issues
Still need "caused by" or "depends on" though.
| It will be reviewed against the standard LTS criteria and either accepted and merged or rejected and closed. | ||
|
|
||
| Pull requests that need to be backported but are not ready yet, should have the label `lts-candidate` applied to them. | ||
| There will be reviewed during the LTS backporting window and the release lead will backport any remaining labelled pull requests. |
There was a problem hiding this comment.
Is there a specific reason why we want to start labeling PRs as lts candidate over issues? I see that regular uses without triage permissions are no longer able to label an issue as lts candidate, but that could be mitigated with an action listening to a command comment, like/lts-candidate for example.
I find that quite handy in order to aggregate an issue overview of lts candidates when reviewing them, considering issues (often) provide more information and insights than a PR does.
LTS candidates could be tracked as a project or milestone, similar to the 2.x-accepted/rejected label on Jira.
Tooling like https://github.com/jenkins-infra/backend-commit-history-parser/tree/master/bin will need an update or gets sunset in favor of a more contemporary workflow.
There was a problem hiding this comment.
Yes I would like to automate the backporting based off of labelling the pull request
This can automatically pull changelog comments across and add all labels required.
It will require minor tooling changes but a better workflow.
I've clarified that issues can still be labelled to show that we want to backport it in the future
There was a problem hiding this comment.
Yes I would like to automate the backporting based off of labelling the pull request
Sounds interesting 👀
| 1. Users updating the assignee so that default assignee logic was re-evaluated and the actual maintainer notified | ||
| 2. Maintainers manually configuring filters in Jira to notify them | ||
|
|
||
| If we do wish to maintain the ability to move issues for anyone or at least org members then we would need to create a small app that has the ability to do this, deploy it somewhere, and configure a webhook at the organization level. |
There was a problem hiding this comment.
That should be available to org members, or in a more restrictive manner, core maintainers (? at least these people have write permissions on named repositories above).
People reporting issues may not always know the appropriate repository to do that on, especially if an issue involves possibly lesser known core components for an end user, like stapler, winstone etc.
There was a problem hiding this comment.
I think no permission level required should be fine, that's what I did with the labels chat ops command.
|
|
||
| GitHub conveys a lot more information about the status of issues, pull requests and releases than Jira does. | ||
| When an issue or pull request link is pasted you can see whether it is open/closed or merged without having to open it. | ||
| On clicking a commit you can see all the releases it appears on. |
There was a problem hiding this comment.
But not an issue which was closed by that commit. (AFAIK)
There was a problem hiding this comment.
No although I think you can do it via search or looking at the pull request itself
| Atlassian announced the link:https://www.atlassian.com/migration/assess/journey-to-cloud[end of life of Jira server] in February of 2021. | ||
| Open source projects may continue being sponsored by creating a link:https://www.atlassian.com/software/views/open-source-license-request[Jira cloud request]. | ||
|
|
||
| Jira cloud has link:https://support.atlassian.com/jira-cloud-administration/docs/explore-jira-cloud-plans/[limitations] that would affect us around: |
There was a problem hiding this comment.
This is a long page and it is unclear which limitations you are referring to.
There was a problem hiding this comment.
there's a list below this with the specific issues, (not detailed but I can expand if it would help)
Co-authored-by: Jesse Glick <[email protected]> Co-authored-by: Alexander Brandes <[email protected]>
… gh-issues-core-components
| It is also common to have a bot that comments on an issue when it has been released in a version. | ||
|
|
||
| e.g. "This has been released in 2.355". | ||
|
|
||
| The benefit of that is it will give a notification to subscribed users that it has been released. |
There was a problem hiding this comment.
Seems like something that might get built into GitHub in the future. The web UI already displays tags & releases including a commit, and it knows that a PR or commit closed an issue.
There was a problem hiding this comment.
FWIW, the "refined github" browser extension shows the corresponding release link on each pull request.
|
Do we want to land it as a JEP draft @timja ? I see technical comments but not the structure ones |
unsure, not planning to work on it for a bit, waiting for a couple of features from GitHub atm |
|
Related: this blog post about a similar migration done by the Spring project. Distinct from the issues raised previously that are specific to the Jenkins project, that blog posts highlights a number of general issues about content migration from Jira markup to GitHub-flavored Markdown. |
No description provided.