@nithinj suggested switching from Jira to Github in another topic (thread). I am moving the discussion here for better visibility. The previous comments from http://community.pbspro.org/t/proposal-for-simplification-of-the-code-contribution-process are:
When are we opening a Github issue tracker for PBSPro? The sooner the better as we are not planning to migrate existing Jira issues. (I know everyone is busy with 18.1 release, so just treat it as a gentle reminder )
Thanks @nithinj – reviewing this thread, I see only positive comments on moving from Jira to Github.
Last call for any more comments or dissent…
If there is still general consensus when PBS Pro v18.1 GA is released (see 18.1 Release Plan), then we will move to Github issue trackers at that time (or there about, depending on how long it takes).
Hi @minghui & all – looks like consensus has been reached!
I feel it would be “bad” to have two systems in operation, so I would like to discuss the best way to transition. That should include updating our process documentation, pull request template, etc., but also if there is some way to label Jira (or make it read-only). (I do not believe we need to transfer open JIRA tickets, but am open to that idea as well.)
Let’s discuss offline, and we can post the plans here, then execute.
Hi all – here is a straw-man task list and proposal for the move (comments/additions encouraged):
- Update Open Confluence (PBS Pro and Developer Guide spaces) replacing Jira instructions and pointers
- Define (initial) Github issue template, proposal is:
- Remind issue filers that Github issues are for reporting new bugs and new RFEs – questions should be posted on community.pbspro.org
- For bugs, ask for: title, version, expected behavior, unexpected behavior seen, and steps to reproduce
- For RFEs, ask for: title, problem description, suggested solution, alternative solutions considered
- Define the (initial) set of Github labels
- Proposal is to use the defaults, renaming “enhancement” to “RFE” and adding “docs” and “PTL”
- Turn on Github Issue Tracker (with defined template and labels)
- Disable creation of new issues in Jira
- Update other references to Issue Tracking, i.e., Jira home page, pbspro.org, pbspro/README.md. Any other places?
- Publish the move and on the Announcements list
- Allow 3 months for people to clone Jira issues they deem important to Github
- After 3 months, shutdown Jira so there is only one place to search for issues
Proposed target is to make the switch in July and de-commission Jira in October.
Again, this is a straw man proposal, so comments are highly encouraged!
Given the recent acquisition of GitHub, we may want to determine whether we’ll be transitioning to GitLab before we adopt the GitHub issue tracker. I think what you’ve provided is equally valid whether we use GutHub or GitLab. I’d prefer to stick with JIRA until that decision is made.
I’m very curious about that and would like to know why the acquisition is a concern, should we start a separate thread about that?
I suggest that this thread isn’t really the place for a (meta) discussion about Microsoft and the future of Github. If people want to have that discussion, please start a separate thread.
It appears there is no longer an overwhelming consensus to move away from Jira, so I would like to take a new poll. If you care, please chime in with one of:
- Move to Github: I want PBS Pro to move to using Github issue trackers
- Keep Jira: I want PBS Pro to keep using Jira issue trackers
- Abstain: Either is OK, I don’t have a strong opinion on one versus the other
At a point where our process does not require us to mandatorily file a Jira ticket for every code change / PR submitted, the overall usage of Jira is actually quite low. While i like github issues, I am not sure whether moving now (after the process to not need a ticket for every PR) actually buys us a lot of benefit. There is cost of movement: We will have to decide how to move the tickets from openjira to issues if we want to migrate them (which affects links in closed PRs)…
There are obvious benefits with moving to issues, like categorizing defects easily etc - if we want them strongly then moving to issues makes sense. Else perhaps wait and see how much Jira is actually getting used?
(Just my 2 cents).
GitLab importer will import all your repository details including issues. A transition will be smooth even if we go ahead with GitHub issue tracker now.
FYI, since there is a community BOF next week at ISC, I’m going to leave the poll open until a week after the BOF to allow for lots of input. Stay tuned…