On Fri, Jun 12, 2020 at 6:07 AM Dominik Bartholdi <d...@fortysix.ch> wrote:
> I fully agrees with Uli and James… the main reason for me is the > searchability of the issue IDs. Many many times I have the JIRA Issue ID > (e.g. in commits) and then a simple Google search brings up the exact issue > - with GH-Issues, this gets lost all the way :( > This seems already possible: https://stackoverflow.com/questions/1687262/link-to-the-issue-number-on-github-within-a-commit-message > On 11 Jun 2020, at 19:25, Ullrich Hafner <ullrich.haf...@gmail.com> wrote: > > > I prefer Jira, from a developer and a user perspective: > > Developer perspective: > - Having the ability to move issues from one component to another is very > helpful for me. I don’t see how to do this in GitHub. My plugin uses > different components and I want to easily move issues from one component to > other components. Also it is very helpful to create issues that affect > several components. It makes inter-project communication much simpler. > > I support what Jesse Glick earlier wrote - our component configuration actually makes the Jira functionality totally useless in terms of things like fixVersion/affectedVersion when all components share the same project - at least in the current configuration shape. > - I also think that Jira has far more powerful features: dashboards, > Kanban boards, epics and sub-tasks, powerful search, IntelliJ integration, > workflows, issue resolution (resolved, fixed, duplicate, etc.), searchable > IDs like JENKINS-50000 that you can enter in Google Search, just to name a > few. It even has a wonderful mobile App (that we currently can’t use since > our Jira version is sooo old). > > The superiority of Jira in terms of features is obvious but it shouldn't be an argument. Most of the projects do not use Sprint Boards etc. and I still think that we should aim to be as close/easy for the contributor/reporter as possible. Most of searchability is achievable via milestones and labels with the additional advantages like auto-labelling by a bot according to PR size etc. I've just tested this: Search for CVSS in jira-plugin issues in my fork, via the global search option (top left): https://github.com/search?q=user%3Awarden+cvss&type=Issues - on my whole account (if I want cross-component search) https://github.com/warden/jira-plugin/search?q=cvss&unscoped_q=cvss - in specific repository(plugin) Maybe we should list all usecases that are being used and try to create a migration table to see if we are missing any crucial stuff? I obviously agree that one of the benefits is indexability of JENKINS-xxxx names by Google that we would loose... OTOH, it's rather a matter of workflow, right? I mean, I don't think you ever remember the issue ID to search in Google, you search for it from the commit message, which if linked properly should work fine (see first link) > Users perspective: > - Searching for all existing issues in Jira is very easy. Selecting > multiple components if the reporter is not sure about the right component > is also very simple. I think users will be annoyed if they need to switch > between two different systems just because the issue has been reported in a > wrong component and in the wrong issue tracker. > > All Jenkins plugins are under the same GH account, IMHO the search UI is actually easier than Jira with lot of dropdown - says Atlassian software lover - but still, Jira is more for product teams in my opinion and for OSS GitHub is just simpler and enough with the advancements they made. I understand that GitHub also has some benefits, like a smooth integration > with commits and PRs, or the fact that we do not need to host it. GitHub is > also fast and modern (but Jira 8.x improved a lot on that side, maybe it > would help to upgrade to a more recent version on our side). > > Now another point, does the Keycloak/Linux Foundation for current Auth/AuthZ thread have any influence on this? Would it make it possible to use Jira Cloud when using any of those? About consistency, I fully agree, but we are already past that point as the plugins are already mixed up between Jira and GH. So unless we want to make a forced pushback to Jira, I would try to make use of the current situation to migrate to either Jira Cloud or GH Issues to get rid of maintenance (and old version) burden, since the blog is also moving out of Confluence. Cheers, Radek -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWigW42sR%3DRpHVsYx%3DggdWhYA7TbB%2B6NJKry%2B%2BQ8QyaWrQ%40mail.gmail.com.
