GitHub issues option in HOSTING

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GitHub issues option in HOSTING

Tim Jacomb

Hi


GitHub issues use is growing in the ecosystem, many plugins are now using it,


Some benefits from my experience in using it:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.


Some repositories that are using them:

https://github.com/jenkinsci/configuration-as-code-plugin, https://github.com/jenkinsci/slack-plugin

https://github.com/jenkinsci/google-compute-engine-plugin

And many more...


I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:

  • Delete issues support - for security fixes, GitHub now supports this

  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.

  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).


I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.


Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.


I would also suggest that we add some text to the Component field that says:

‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.


Any feedback or questions?


Thanks

Tim


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

GitHub issues option in HOSTING

Oleg Nenashev
As discussed at the contributor summit, I am totally in favor of opening the GitHub issues a bit more, and maybe even making it default for new plugins. Thanks Tim for starting thus thread!

Regarding the implementation, my proposal would be to firstly add explicit issue tracker links on the plugin site. Maven metadata already supports it, we just need to expose it in the update center.

Then we could, for example, keep components and use a Jira bot when an issue is misreported.

Just removing a component will have limited impact, because many components are often not reported to a right component anyway (triage is needed, or users just report it wrongly). Removing components is likely to encourage people to take another random component or _unsorted  

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fb498730-4b7c-498e-9f09-46bd6e95805b%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Ulli Hafner
In reply to this post by Tim Jacomb
I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location (i.e., GitHub) we should also enforce (well at least work towards) a unique landing page for issues from our users. Otherwise users are confused where to report issues, where to look for existing issues etc. 

Also it makes inter-project communication for developers more complicated. Very often issues are not only related to one component, and currently it is quite easy to ping the component lead of the other component or to reassign to a different component, etc. For instance, some time ago I reported an incompatibility of a Jenkins plugin with the JCasC plugin: it was very cumbersome to check if I should use GitHub or Jira to report the issue. 

What might make sense to discuss is, if we should replace Jira with GitHub issues for all projects? I doubt that GitHub issues are already a replacement for such a sophisticated tool like Jira, but maybe other developers see that differently. 

On the other hand, maybe we can improve our existing development process so that the missing peaces from your requirements get integrated into Jira:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

This is quite easy in Jira as well.

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

I think I don’t get the point here, maybe you need to clarify why Jira is here more complex

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
  
We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task. 

Am 02.02.2020 um 12:13 schrieb Tim Jacomb <[hidden email]>:

Hi

GitHub issues use is growing in the ecosystem, many plugins are now using it,

Some benefits from my experience in using it:
  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain
  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.

Some repositories that are using them:
And many more...

I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:
  • Delete issues support - for security fixes, GitHub now supports this
  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.
  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).

I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.

Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

I would also suggest that we add some text to the Component field that says:
‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

Any feedback or questions?

Thanks
Tim


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5CC28676-5E82-4F78-B6E0-374F88680E77%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Joseph P
As a maintainer I find it very difficult that I have to use Jira for inter project work.

- Question what username you have on Jira not always the same
- find Jira searching very bothersome compared to some of the logical either code searches or be it issue searches.
  - Tim and I have been very thankful to be able to search across JenkinsCI org on github.
     Here is a good example of inter project communication: https://github.com/jenkinsci/bom/pull/172

- do not find components very useful.
  - Have to ask to be made default assignee
    - That means going to IRC and poking people 👻
  - I might miss someone because only one can be assigned and people do not use watchers.
    - find it a lot easier to look in the pom.xml or see commit history and ping those who might know something on github.
  - Getting these dreaded emails that just keep pilling up in our inbox 😰.
    - Prefer github that allows you to subscribe and unsubscribe and their web notifications JUST WORKS and even better with the new Notification beta.
  - often forget in Jira on the components that might interest me.
  - You have to be a JQL wizard to find anything again! 🧙‍♂️

- Jira is slow compared to GitHub.

- Jira integration is just bad compared to what you can get from interlinking issues and pull requests on GitHub.

- Jenkins already has a bad situation of too many systems to handle messaging and source configuration management. Case in point being this mailing list 😅
  - Would be awesome to simplify on a single chat platform and a single SCM.

Again finding something again in Jenkins means I have to look either into mailing lists, Jira, confluence, IRC, gitter, slack or GitHub.
Perhaps I missed something.

Would be great if we could boil it down to two 🤯

For crying out loud I had to ask on GitHub where to find this body of work: https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871


On Sunday, February 2, 2020 at 3:10:33 PM UTC+1, Ullrich Hafner wrote:
I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location (i.e., GitHub) we should also enforce (well at least work towards) a unique landing page for issues from our users. Otherwise users are confused where to report issues, where to look for existing issues etc. 

Also it makes inter-project communication for developers more complicated. Very often issues are not only related to one component, and currently it is quite easy to ping the component lead of the other component or to reassign to a different component, etc. For instance, some time ago I reported an incompatibility of a Jenkins plugin with the JCasC plugin: it was very cumbersome to check if I should use GitHub or Jira to report the issue. 

What might make sense to discuss is, if we should replace Jira with GitHub issues for all projects? I doubt that GitHub issues are already a replacement for such a sophisticated tool like Jira, but maybe other developers see that differently. 

On the other hand, maybe we can improve our existing development process so that the missing peaces from your requirements get integrated into Jira:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

This is quite easy in Jira as well.

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

I think I don’t get the point here, maybe you need to clarify why Jira is here more complex

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
  
We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task. 

Am 02.02.2020 um 12:13 schrieb Tim Jacomb <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="P_gg3pxYAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">timja...@...>:

Hi

GitHub issues use is growing in the ecosystem, many plugins are now using it,

Some benefits from my experience in using it:
  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain
  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.

Some repositories that are using them:
<a href="https://github.com/jenkinsci/configuration-as-code-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fconfiguration-as-code-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEBFSLRRiRNYGWqAZr6GdCRCYi73w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fconfiguration-as-code-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEBFSLRRiRNYGWqAZr6GdCRCYi73w&#39;;return true;">https://github.com/jenkinsci/configuration-as-code-plugin, <a href="https://github.com/jenkinsci/slack-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fslack-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQaPp-X5Vesjb2XO2VNH6DdkXsXg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fslack-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQaPp-X5Vesjb2XO2VNH6DdkXsXg&#39;;return true;">https://github.com/jenkinsci/slack-plugin
<a href="https://github.com/jenkinsci/google-compute-engine-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgoogle-compute-engine-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH--3H80ph7u0QyWsn2Thds1cwspA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgoogle-compute-engine-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH--3H80ph7u0QyWsn2Thds1cwspA&#39;;return true;">https://github.com/jenkinsci/google-compute-engine-plugin
And many more...

I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:
  • Delete issues support - for security fixes, GitHub now supports this
  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.
  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects <a href="https://github.com/orgs/jenkinsci/projects/3" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fprojects%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSFAVNvfzCR-eetpDetEZOLr2wZw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fprojects%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSFAVNvfzCR-eetpDetEZOLr2wZw&#39;;return true;">https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), <a href="https://github.com/orgs/jenkinsci/projects/1" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fprojects%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGR3s6dmVS3l1fTBN2jBoKLVVORg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fprojects%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGR3s6dmVS3l1fTBN2jBoKLVVORg&#39;;return true;">https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).

I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.

Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

I would also suggest that we add some text to the Component field that says:
‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

Any feedback or questions?

Thanks
Tim


--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="P_gg3pxYAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkin...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7f2ffee6-9a49-475f-afa8-e09628527d0f%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Chris Kilding
I'm inclined to agree with Joseph and Tim.

When maintaining my plugin I often wonder how many bug reports I'm losing because users either:

- Can't find their way through our bug tracking system (and all the labels and categories that a bug must be annotated with), compared to GH Issues which is very simple.
- Get discouraged from reporting a bug because they're more annoyed by making yet another online account / username + password.

Occasionally, users have reported their bugs in comments on active GitHub PRs where wholly different bugs are being worked on, as this is the only way they've been able to reach out within the GitHub ecosystem, and it's still lower friction than Jira.

My plugin is a leaf node in the plugin ecosystem, i.e. it is an implementation of a Jenkins API with no further code dependents. Possibly as a result, issues that have been reported tend not to reach beyond the plugin itself in scope, and I've never seen an issue that was incorrectly reported (and needed to be transferred). This category of plugins would be ideal to move to GH issues as a first step.

Chris

On Sun, 2 Feb 2020, at 3:34 PM, Joseph P wrote:
As a maintainer I find it very difficult that I have to use Jira for inter project work.

- Question what username you have on Jira not always the same
- find Jira searching very bothersome compared to some of the logical either code searches or be it issue searches.
  - Tim and I have been very thankful to be able to search across JenkinsCI org on github.
     Here is a good example of inter project communication: https://github.com/jenkinsci/bom/pull/172

- do not find components very useful.
  - Have to ask to be made default assignee
    - That means going to IRC and poking people 👻
  - I might miss someone because only one can be assigned and people do not use watchers.
    - find it a lot easier to look in the pom.xml or see commit history and ping those who might know something on github.
  - Getting these dreaded emails that just keep pilling up in our inbox 😰.
    - Prefer github that allows you to subscribe and unsubscribe and their web notifications JUST WORKS and even better with the new Notification beta.
  - often forget in Jira on the components that might interest me.
  - You have to be a JQL wizard to find anything again! 🧙‍♂️

- Jira is slow compared to GitHub.

- Jira integration is just bad compared to what you can get from interlinking issues and pull requests on GitHub.

- Jenkins already has a bad situation of too many systems to handle messaging and source configuration management. Case in point being this mailing list 😅
  - Would be awesome to simplify on a single chat platform and a single SCM.

Again finding something again in Jenkins means I have to look either into mailing lists, Jira, confluence, IRC, gitter, slack or GitHub.
Perhaps I missed something.

Would be great if we could boil it down to two 🤯

For crying out loud I had to ask on GitHub where to find this body of work: https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871


On Sunday, February 2, 2020 at 3:10:33 PM UTC+1, Ullrich Hafner wrote:
I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location (i.e., GitHub) we should also enforce (well at least work towards) a unique landing page for issues from our users. Otherwise users are confused where to report issues, where to look for existing issues etc. 

Also it makes inter-project communication for developers more complicated. Very often issues are not only related to one component, and currently it is quite easy to ping the component lead of the other component or to reassign to a different component, etc. For instance, some time ago I reported an incompatibility of a Jenkins plugin with the JCasC plugin: it was very cumbersome to check if I should use GitHub or Jira to report the issue. 

What might make sense to discuss is, if we should replace Jira with GitHub issues for all projects? I doubt that GitHub issues are already a replacement for such a sophisticated tool like Jira, but maybe other developers see that differently. 

On the other hand, maybe we can improve our existing development process so that the missing peaces from your requirements get integrated into Jira:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

This is quite easy in Jira as well.

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

I think I don’t get the point here, maybe you need to clarify why Jira is here more complex

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
  
We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task. 

Am 02.02.2020 um 12:13 schrieb Tim Jacomb <[hidden email]>:

Hi

GitHub issues use is growing in the ecosystem, many plugins are now using it,

Some benefits from my experience in using it:
  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain
  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.

Some repositories that are using them:
And many more...

I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:
  • Delete issues support - for security fixes, GitHub now supports this
  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.
  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).

I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.

Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

I would also suggest that we add some text to the Component field that says:
‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

Any feedback or questions?

Thanks
Tim


--
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 jenkin...@googlegroups.com.


--
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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56145d0a-7eb1-4414-ad5b-a7991d8b918d%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
Any other opinions?

So far we have 3 +1, and 1 -1

This isn't asking that we move everything over, but make it easier for new plugin maintainers to use GitHub issues.

Thanks
Tim

On Mon, 3 Feb 2020 at 13:06, Chris Kilding <[hidden email]> wrote:
I'm inclined to agree with Joseph and Tim.

When maintaining my plugin I often wonder how many bug reports I'm losing because users either:

- Can't find their way through our bug tracking system (and all the labels and categories that a bug must be annotated with), compared to GH Issues which is very simple.
- Get discouraged from reporting a bug because they're more annoyed by making yet another online account / username + password.

Occasionally, users have reported their bugs in comments on active GitHub PRs where wholly different bugs are being worked on, as this is the only way they've been able to reach out within the GitHub ecosystem, and it's still lower friction than Jira.

My plugin is a leaf node in the plugin ecosystem, i.e. it is an implementation of a Jenkins API with no further code dependents. Possibly as a result, issues that have been reported tend not to reach beyond the plugin itself in scope, and I've never seen an issue that was incorrectly reported (and needed to be transferred). This category of plugins would be ideal to move to GH issues as a first step.

Chris

On Sun, 2 Feb 2020, at 3:34 PM, Joseph P wrote:
As a maintainer I find it very difficult that I have to use Jira for inter project work.

- Question what username you have on Jira not always the same
- find Jira searching very bothersome compared to some of the logical either code searches or be it issue searches.
  - Tim and I have been very thankful to be able to search across JenkinsCI org on github.
     Here is a good example of inter project communication: https://github.com/jenkinsci/bom/pull/172

- do not find components very useful.
  - Have to ask to be made default assignee
    - That means going to IRC and poking people 👻
  - I might miss someone because only one can be assigned and people do not use watchers.
    - find it a lot easier to look in the pom.xml or see commit history and ping those who might know something on github.
  - Getting these dreaded emails that just keep pilling up in our inbox 😰.
    - Prefer github that allows you to subscribe and unsubscribe and their web notifications JUST WORKS and even better with the new Notification beta.
  - often forget in Jira on the components that might interest me.
  - You have to be a JQL wizard to find anything again! 🧙‍♂️

- Jira is slow compared to GitHub.

- Jira integration is just bad compared to what you can get from interlinking issues and pull requests on GitHub.

- Jenkins already has a bad situation of too many systems to handle messaging and source configuration management. Case in point being this mailing list 😅
  - Would be awesome to simplify on a single chat platform and a single SCM.

Again finding something again in Jenkins means I have to look either into mailing lists, Jira, confluence, IRC, gitter, slack or GitHub.
Perhaps I missed something.

Would be great if we could boil it down to two 🤯

For crying out loud I had to ask on GitHub where to find this body of work: https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871


On Sunday, February 2, 2020 at 3:10:33 PM UTC+1, Ullrich Hafner wrote:
I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location (i.e., GitHub) we should also enforce (well at least work towards) a unique landing page for issues from our users. Otherwise users are confused where to report issues, where to look for existing issues etc. 

Also it makes inter-project communication for developers more complicated. Very often issues are not only related to one component, and currently it is quite easy to ping the component lead of the other component or to reassign to a different component, etc. For instance, some time ago I reported an incompatibility of a Jenkins plugin with the JCasC plugin: it was very cumbersome to check if I should use GitHub or Jira to report the issue. 

What might make sense to discuss is, if we should replace Jira with GitHub issues for all projects? I doubt that GitHub issues are already a replacement for such a sophisticated tool like Jira, but maybe other developers see that differently. 

On the other hand, maybe we can improve our existing development process so that the missing peaces from your requirements get integrated into Jira:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

This is quite easy in Jira as well.

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

I think I don’t get the point here, maybe you need to clarify why Jira is here more complex

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
  
We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task. 

Am 02.02.2020 um 12:13 schrieb Tim Jacomb <[hidden email]>:

Hi

GitHub issues use is growing in the ecosystem, many plugins are now using it,

Some benefits from my experience in using it:
  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain
  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.

Some repositories that are using them:
And many more...

I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:
  • Delete issues support - for security fixes, GitHub now supports this
  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.
  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).

I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.

Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

I would also suggest that we add some text to the Component field that says:
‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

Any feedback or questions?

Thanks
Tim


--
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 [hidden email].


--
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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56145d0a-7eb1-4414-ad5b-a7991d8b918d%40www.fastmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie8jJ%2BY_RrFQD%2BJ_qChjdHN7evrjtJ93viavVRKsCaE2A%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Olblak-2
Maintaining issues.jenkins-ci.org is time-consuming, and it's hard to find someone who wants to do it.
While I totally agree that we shouldn't use multiple ticket system, I don't see real good solution he
re

We migrate from Jira to Jira Cloud
-> We keep the history
-> No maintenance
-> There is a GitHub Jira <> integration
-> Mobile app support

We migrate from Jira to Github Issues
-> We lose the ticket's history
-> No maintenance
-> We can use our GitHub account
-> Everything in one place
-> Github issues is a common workflow compared to other OSS projects
-> Github issues can't be used for security or any other private issues
-> We can configure GitHub with https://github.com/probot/settings

We stay on issues.jenkins-ci.org
-> Not really in favor of that, for all the reasons mention here, more we have a hard deadline in September to upgrade wiki.jenkins-ci.org

I am also considering GitHub issues for the infra project even if GitHub issues is not an option for security issues

Remark: Atlassian has a nice sponsoring program so as far as I remember we can use everything for free

So to answer the question, I would be in favor to experiment using GitHub issues for the hosting project with one project at the organization level for cross repository work

---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---


On Fri, Feb 7, 2020, at 10:33 AM, Tim Jacomb wrote:
Any other opinions?

So far we have 3 +1, and 1 -1

This isn't asking that we move everything over, but make it easier for new plugin maintainers to use GitHub issues.

Thanks
Tim

On Mon, 3 Feb 2020 at 13:06, Chris Kilding <[hidden email]> wrote:

I'm inclined to agree with Joseph and Tim.

When maintaining my plugin I often wonder how many bug reports I'm losing because users either:

- Can't find their way through our bug tracking system (and all the labels and categories that a bug must be annotated with), compared to GH Issues which is very simple.
- Get discouraged from reporting a bug because they're more annoyed by making yet another online account / username + password.

Occasionally, users have reported their bugs in comments on active GitHub PRs where wholly different bugs are being worked on, as this is the only way they've been able to reach out within the GitHub ecosystem, and it's still lower friction than Jira.

My plugin is a leaf node in the plugin ecosystem, i.e. it is an implementation of a Jenkins API with no further code dependents. Possibly as a result, issues that have been reported tend not to reach beyond the plugin itself in scope, and I've never seen an issue that was incorrectly reported (and needed to be transferred). This category of plugins would be ideal to move to GH issues as a first step.

Chris

On Sun, 2 Feb 2020, at 3:34 PM, Joseph P wrote:
As a maintainer I find it very difficult that I have to use Jira for inter project work.

- Question what username you have on Jira not always the same
- find Jira searching very bothersome compared to some of the logical either code searches or be it issue searches.
  - Tim and I have been very thankful to be able to search across JenkinsCI org on github.
     Here is a good example of inter project communication: https://github.com/jenkinsci/bom/pull/172

- do not find components very useful.
  - Have to ask to be made default assignee
    - That means going to IRC and poking people 👻
  - I might miss someone because only one can be assigned and people do not use watchers.
    - find it a lot easier to look in the pom.xml or see commit history and ping those who might know something on github.
  - Getting these dreaded emails that just keep pilling up in our inbox 😰.
    - Prefer github that allows you to subscribe and unsubscribe and their web notifications JUST WORKS and even better with the new Notification beta.
  - often forget in Jira on the components that might interest me.
  - You have to be a JQL wizard to find anything again! 🧙‍♂️

- Jira is slow compared to GitHub.

- Jira integration is just bad compared to what you can get from interlinking issues and pull requests on GitHub.

- Jenkins already has a bad situation of too many systems to handle messaging and source configuration management. Case in point being this mailing list 😅
  - Would be awesome to simplify on a single chat platform and a single SCM.

Again finding something again in Jenkins means I have to look either into mailing lists, Jira, confluence, IRC, gitter, slack or GitHub.
Perhaps I missed something.

Would be great if we could boil it down to two 🤯

For crying out loud I had to ask on GitHub where to find this body of work: https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871


On Sunday, February 2, 2020 at 3:10:33 PM UTC+1, Ullrich Hafner wrote:
I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location (i.e., GitHub) we should also enforce (well at least work towards) a unique landing page for issues from our users. Otherwise users are confused where to report issues, where to look for existing issues etc. 

Also it makes inter-project communication for developers more complicated. Very often issues are not only related to one component, and currently it is quite easy to ping the component lead of the other component or to reassign to a different component, etc. For instance, some time ago I reported an incompatibility of a Jenkins plugin with the JCasC plugin: it was very cumbersome to check if I should use GitHub or Jira to report the issue. 

What might make sense to discuss is, if we should replace Jira with GitHub issues for all projects? I doubt that GitHub issues are already a replacement for such a sophisticated tool like Jira, but maybe other developers see that differently. 

On the other hand, maybe we can improve our existing development process so that the missing peaces from your requirements get integrated into Jira:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

This is quite easy in Jira as well.

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

I think I don’t get the point here, maybe you need to clarify why Jira is here more complex

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
  
We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task. 

Am 02.02.2020 um 12:13 schrieb Tim Jacomb <[hidden email]>:

Hi

GitHub issues use is growing in the ecosystem, many plugins are now using it,

Some benefits from my experience in using it:
  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain
  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.

Some repositories that are using them:
And many more...

I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:
  • Delete issues support - for security fixes, GitHub now supports this
  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.
  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).

I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.

Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

I would also suggest that we add some text to the Component field that says:
‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

Any feedback or questions?

Thanks
Tim


--
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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/43a24a8b-2752-415f-9250-e16886ebab66%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Jesse Glick-4
On Fri, Feb 7, 2020 at 8:50 AM Olblak <[hidden email]> wrote:
> We migrate from Jira to Jira Cloud
> We migrate from Jira to Github Issues

Can we migrate to Jira Cloud with history intact, _and_ encourage use
of GitHub issues for new components?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2S%3D%2BCb-xNpsARz%2BX5U4XapzrfWZ2PSjkKZmft9usk-7g%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

slide
For maintaining history, I've done something similar in the past when migrating a project from codeplex to GitHub. The script I had migrated the comments and the attachments as best it could. I could try a proof of concept of people are interested.

On Fri, Feb 7, 2020, 07:06 Jesse Glick <[hidden email]> wrote:
On Fri, Feb 7, 2020 at 8:50 AM Olblak <[hidden email]> wrote:
> We migrate from Jira to Jira Cloud
> We migrate from Jira to Github Issues

Can we migrate to Jira Cloud with history intact, _and_ encourage use
of GitHub issues for new components?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2S%3D%2BCb-xNpsARz%2BX5U4XapzrfWZ2PSjkKZmft9usk-7g%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVe31EK8uqUQWay5Cwq3YXh_pSreESCANKCj6qheGyy60w%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

James Nord-2
I generally agree with Ulli's comments.

so far we are all talking about the developer experience when interacting with issues.  we need to also think of the user experience to Jenkins users too.  it kills me every time I need to file an issue and try and work out where it is to be reported and I consider myself knowledgeable about Jenkins and it's plugins.  

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/61d3f5f3-106c-4bf5-a032-33b59be2f23b%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Olblak-2
Technically we could migrate all issues to github, at least I saw some python scripts doing that. I would be more concerned by the security issues, so indeed we could also have both tools in place where most of the things are on github issues

---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---

On Fri, Feb 7, 2020, at 3:56 PM, James Nord wrote:

> I generally agree with Ulli's comments.
>
> so far we are all talking about the developer experience when
> interacting with issues.  we need to also think of the user experience
> to Jenkins users too.  it kills me every time I need to file an issue
> and try and work out where it is to be reported and I consider myself
> knowledgeable about Jenkins and it's plugins.  
>
> --
> 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 [hidden email].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/61d3f5f3-106c-4bf5-a032-33b59be2f23b%40googlegroups.com.
>

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/870c9b3a-dc13-4003-80c9-a2f0162ad0b2%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck
In reply to this post by Tim Jacomb


> On 2. Feb 2020, at 12:13, Tim Jacomb <[hidden email]> wrote:
>
> • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

At least you have the option to. I use several Jira dashboards optimized for various tasks, and dread having to replace them with bookmarks to gitHub.com/issues

> I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.
>
> Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

This seems reasonable. If they don't want a component in Jira, they don't get one.

>
> I would also suggest that we add some text to the Component field that says:
> ‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

"Cool, where do I find that?"

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3FC000E7-0D66-441D-A1B6-DCE8394CEF9C%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck
In reply to this post by Ulli Hafner


> On 2. Feb 2020, at 15:10, Ullrich Hafner <[hidden email]> wrote:
>
> I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location … it was very cumbersome to check if I should use GitHub or Jira to report the issue.  … replace Jira with GitHub issues for all projects?

Many years ago we didn't really allow GitHub issues (no admin permissions before GitHub allowed disabling destructive actions). Everything was in Jira. Then people wanted to use GH issues, despite some objections, including mine, that this will be pretty hostile to users. Now some popular plugins use GH issues, and suddenly everyone is supposed to migrate, because having two systems is bad? Maybe maintainers should have considered that before they clicked "[x] Enable issue tracker" despite having a Jira component…

FWIW a recent proposal would add a link to the appropriate issue tracker to the plugin metadata, which can be exposed in the plugin site and/or Jenkins directly. That would take care of the "where to report" problem.


> We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task.

We had it for a while, but it used too many API calls and went above the allowed API quota. There should be threads on the infra list. Maybe it's better now?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4AF66E6A-3B55-4A10-BEA4-3D69D948FB5A%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck
In reply to this post by James Nord-2


> On 7. Feb 2020, at 15:56, James Nord <[hidden email]> wrote:
>
> it kills me every time I need to file an issue and try and work out where it is to be reported and I consider myself knowledgeable about Jenkins and it's plugins.  

I mentioned it in a previous response, but here's the link: https://github.com/jenkins-infra/update-center2/pull/331

This has the potential to make this easier than ever before.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D8A0D08A-14C9-4082-8262-DF45D210B4A2%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

I think the big push in the past for jira was because you couldn't migrate issues between repos before in github. That got changed.. though you still need write permission in both repos, so regular users can't migrate issues - https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repository - so its better, but not great. Most users are randomly guessing what components to assign things to, often just using the auto complete. For example, https://issues.jenkins-ci.org/browse/JENKINS-44148 I added the core component because after digging around on the pipeline steps doc, I learned that archiveArtifact is a "core" step. Though now that I think about it, it probably means the basic pipeline steps. Its really hard to figure out which component/repo pipeline issues should go into.

With github I can "watch" the entire repo, so new PRs and new issues get emailed to me. Doesn't matter if i'm the maintainer (single or multiple), or just a random user trying to help out.

With jira, I'm either auto assigned the issue due to whatever component was first picked, or nothing at all. Groups of maintainers can't be notified. Un-assigned tickets don't get notified. I like many others don't want to assign it to me until I'm working on it, so someone else could take it if they wanted.
I will say the cloud model of jira is super easy to make plugins for now, and I bet if we could reach out to https://marketplace.atlassian.com/apps/1213851/watch-it-for-jira-cloud?hosting=cloud&tab=overview to get some sort of open source deal.

So far no solution is great for me, I'm a slight preference for github (but maybe jira cloud if auto watching can be handled), but I agree fully that consistency is good. I never really look at jira as it stands right now its such a huge mess.

Gavin

On Fri, Feb 7, 2020 at 10:04 AM Daniel Beck <[hidden email]> wrote:


> On 7. Feb 2020, at 15:56, James Nord <[hidden email]> wrote:
>
> it kills me every time I need to file an issue and try and work out where it is to be reported and I consider myself knowledgeable about Jenkins and it's plugins. 

I mentioned it in a previous response, but here's the link: https://github.com/jenkins-infra/update-center2/pull/331

This has the potential to make this easier than ever before.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D8A0D08A-14C9-4082-8262-DF45D210B4A2%40beckweb.net.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusfHM4OAK23Sgwh_UhY4X71sCRkh6RvG%2BRxYKc9FX4VkA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

James Nord-2
>With jira, I'm either auto assigned the issue due to whatever component was first picked, or nothing at all. Groups of maintainers can't be notified. Un-assigned tickets don't get notified

create a filter that matches things you want to be notified for.
subscribe to that filter in https://issues.jenkins-ci.org/secure/ManageFilters.jspa

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5073d833-537b-4d84-a52d-d5fed2cb18f0%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
Oh cool, I didn't know about that feature.

On Fri, Feb 7, 2020 at 5:35 PM James Nord <[hidden email]> wrote:
>With jira, I'm either auto assigned the issue due to whatever component was first picked, or nothing at all. Groups of maintainers can't be notified. Un-assigned tickets don't get notified

create a filter that matches things you want to be notified for.
subscribe to that filter in https://issues.jenkins-ci.org/secure/ManageFilters.jspa

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5073d833-537b-4d84-a52d-d5fed2cb18f0%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duu-AbFFbjFGD0d_vrzDD4F3Sbb%3Doa-VDUzgteQzJARi9g%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck-2
In reply to this post by Gavin Mogan

On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

When was the last time our Jira instance had performance/availability problems? I don't think there have been any problems so far this year, and probably not to a notable degree in the last few months of last year...

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLqd%3DLAjBGwxPP5%2BdkTp%2Bof1L0AUetZ5HdLj6Cu%2BZZ86w%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
(replies inline)
On Sat, 8 Feb 2020 at 12:13, Daniel Beck <[hidden email]> wrote:

On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

When was the last time our Jira instance had performance/availability problems? I don't think there have been any problems so far this year, and probably not to a notable degree in the last few months of last year...


 Now?
image.png
It takes me 9 seconds to open JIRA for it to be interactive.
And then I have to log in every single time...

Compared to GitHub issues which is:
image.png
~3 seconds to be fully done, but I can interact with the page after 2 seconds.
And I'm already logged in so I don't need to spend another 15 seconds logging in.

I've definitely clicked to open a JIRA issue before and then not distracted while it was loading...

Thanks
Tim

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLqd%3DLAjBGwxPP5%2BdkTp%2Bof1L0AUetZ5HdLj6Cu%2BZZ86w%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidGCCf%3DvSNUqfVhG_3ZBqQykJZ5h%3DYpDHLnm2BsND9%2Bpg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck-2


On Sat, Feb 8, 2020 at 2:46 PM Tim Jacomb <[hidden email]> wrote:
(replies inline)
On Sat, 8 Feb 2020 at 12:13, Daniel Beck <[hidden email]> wrote:

On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

When was the last time our Jira instance had performance/availability problems? I don't think there have been any problems so far this year, and probably not to a notable degree in the last few months of last year...


 Now?
image.png
It takes me 9 seconds to open JIRA for it to be interactive.
And then I have to log in every single time...

The only view that even comes close to that for me is the System Default dashboard when not logged in, is that what I'm seeing here?(How about following an issue link from the changelog?)

I have five custom dashboards, so I never see the default one -- and opening issues is almost instantaneous for me. Otherwise I'd go crazy, updating dozens of issues every week for the past several years.

I'm also not logged out more than once a week or so. Is it possible that you're rarely using Jira to begin with?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BQsV%3DxJEGMdo1NU%3D5PxiMbE6c8bbMu7SrKmHcC06Fn%3Dg%40mail.gmail.com.
12