GitHub issues option in HOSTING

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
So re surfacing this old topic now that we've merged and deployed the updated plugin site with GitHub releases and jira issues 

My next steps is start supporting GitHub issues for plugins that uses them. But this topic never came to a conclusion.

If we are officially supporting GitHub issues, then I think the only remaining issue is how to move incorrectly files issues. I think you need triage or write access to migrate an issue, so I'd like to see a bot that has access to move to either a) everyone b) everyone with write access to Jenkins org or c) with write to either source or destination repo.

My vote is b.

I'd like a final conclusion and an "official response" before I clean up the PRs for update center and plugin site API.


On Thu., Mar. 26, 2020, 3:28 a.m. Radosław Antoniuk, <[hidden email]> wrote:
I used this one: https://github.com/warden/jira-issues-importer

--
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/CAPe2pWjopjvpX%2B_oRKZ%2BW6PCsDaJj5NpUtRnj-YdJGY0t1zrdg%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/CAG%3D_Dutik45JTvY6YznY9qs8Za6Wca%3DaL1BXiKvWaoDcW0RZcw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Ulli Hafner

Am 10.06.2020 um 01:24 schrieb 'Gavin Mogan' via Jenkins Developers <[hidden email]>:

So re surfacing this old topic now that we've merged and deployed the updated plugin site with GitHub releases and jira issues 


Seems that I overlooked the PR for the new plugins site. Nice work, thanks for that! 

My next steps is start supporting GitHub issues for plugins that uses them. But this topic never came to a conclusion.

If we are officially supporting GitHub issues,

I think this has not been decided yet...

then I think the only remaining issue is how to move incorrectly files issues. I think you need triage or write access to migrate an issue, so I'd like to see a bot that has access to move to either a) everyone b) everyone with write access to Jenkins org or c) with write to either source or destination repo.

My vote is b.


I’m not sure if I can follow: you want to have a bot that syncs Jira and GitHub? Or is it a one-way from Jira to GitHub?

I'd like a final conclusion and an "official response" before I clean up the PRs for update center and plugin site API.


On Thu., Mar. 26, 2020, 3:28 a.m. Radosław Antoniuk, <[hidden email]> wrote:
I used this one: https://github.com/warden/jira-issues-importer

--
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/CAPe2pWjopjvpX%2B_oRKZ%2BW6PCsDaJj5NpUtRnj-YdJGY0t1zrdg%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/CAG%3D_Dutik45JTvY6YznY9qs8Za6Wca%3DaL1BXiKvWaoDcW0RZcw%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/F6588E45-6D0F-4F85-81C5-7BC83A031862%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
Yea I want to get the discussion restarted so a conclusion can happen.

And no, was just thinking of transferring tickets between plugins that do GitHub issues. And the triaging issues within, but yea that's another issue with the mixed env

On Wed., Jun. 10, 2020, 1:14 a.m. Ullrich Hafner, <[hidden email]> wrote:

Am 10.06.2020 um 01:24 schrieb 'Gavin Mogan' via Jenkins Developers <[hidden email]>:

So re surfacing this old topic now that we've merged and deployed the updated plugin site with GitHub releases and jira issues 


Seems that I overlooked the PR for the new plugins site. Nice work, thanks for that! 

My next steps is start supporting GitHub issues for plugins that uses them. But this topic never came to a conclusion.

If we are officially supporting GitHub issues,

I think this has not been decided yet...

then I think the only remaining issue is how to move incorrectly files issues. I think you need triage or write access to migrate an issue, so I'd like to see a bot that has access to move to either a) everyone b) everyone with write access to Jenkins org or c) with write to either source or destination repo.

My vote is b.


I’m not sure if I can follow: you want to have a bot that syncs Jira and GitHub? Or is it a one-way from Jira to GitHub?

I'd like a final conclusion and an "official response" before I clean up the PRs for update center and plugin site API.


On Thu., Mar. 26, 2020, 3:28 a.m. Radosław Antoniuk, <[hidden email]> wrote:
I used this one: https://github.com/warden/jira-issues-importer

--
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/CAPe2pWjopjvpX%2B_oRKZ%2BW6PCsDaJj5NpUtRnj-YdJGY0t1zrdg%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/CAG%3D_Dutik45JTvY6YznY9qs8Za6Wca%3DaL1BXiKvWaoDcW0RZcw%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/F6588E45-6D0F-4F85-81C5-7BC83A031862%40gmail.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_Dut5nQhmCcQEx%3Dh2tdqWswPBbbO5bTHrhC2v1JvrDr7Fww%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk
Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).
The question is how to prevent opening new issues in Jira afterwards, but this actually could be automated via a simple JQL looking for open issues in Jira that would be auto-closed with a message: "please report on plugin's github issues".

--
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/CAPe2pWju%3DbHwSqCRUVo%3DzpgS%3DsTpEu9oorxAN_37nW_tG8QBhw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

slide
We could remove the component from Kira for the plugin. It wouldn't stop someone from opening one and assigning it to the wrong component, but people assign to the wrong component all the time anyway.

On Wed, Jun 10, 2020, 02:47 Radosław Antoniuk <[hidden email]> wrote:
Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).
The question is how to prevent opening new issues in Jira afterwards, but this actually could be automated via a simple JQL looking for open issues in Jira that would be auto-closed with a message: "please report on plugin's github issues".

--
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/CAPe2pWju%3DbHwSqCRUVo%3DzpgS%3DsTpEu9oorxAN_37nW_tG8QBhw%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/CAPiUgVdPecBxcKbUHwbh9kPSCRL6Eh3%2Ba6Z%2BoM7CabRqcSDLhA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk
On Wed, Jun 10, 2020 at 3:46 PM Slide <[hidden email]> wrote:
We could remove the component from Kira for the plugin. It wouldn't stop someone from opening one and assigning it to the wrong component, but people assign to the wrong component all the time anyway.

Yes, removing the category is the other option I thought about, +1 on this as the simplest way to proceed.
Note the downside however that removing the category would remove it from all the existing old issues as well.
 

--
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/CAPe2pWh%2BTMqxEhbsxhqHM-01fmRU81vifPh%3DsTwwVFRz3-n5gg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Ulli Hafner
In reply to this post by Radosław Antoniuk

Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <[hidden email]>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


The question is how to prevent opening new issues in Jira afterwards, but this actually could be automated via a simple JQL looking for open issues in Jira that would be auto-closed with a message: "please report on plugin's github issues".


--
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/CAPe2pWju%3DbHwSqCRUVo%3DzpgS%3DsTpEu9oorxAN_37nW_tG8QBhw%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/7668387D-FF80-4970-97A4-1DCB50A2B9AF%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <[hidden email]>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


From standarisation and a common approach standpoint, forcing all plugins to use Jira would be reasonable if not for:
- stability problems
- maintenance problems (it is not updated frequently enough imo)
- lack of common process (I don't like for instance that we cannot use fixVersion in the workflow)

All of those could be probably addressed but OTOH, we are also too late with forcing to use Jira as a lot of plugins are already using GH issues and frankly as we discsussed before, I concur with GH Issues being closer to code/repository and easier for maintainers.
So, if each repository/plugin has it's own maintainer and noone from the umbrella organisation, then it should be up to the plugin maintainers to decide what they use - and we already see the tendency here.

--
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/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
personally, as someone who replies to emails/tickets on my phone a lot, I'd love to see everything migrated from self hosted jira to github, and have one less item that the infra team needs to manage. Plus easier for people to report bugs since they don't need to make an ldap account first

On Wed, Jun 10, 2020 at 7:06 AM Radosław Antoniuk <[hidden email]> wrote:
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <[hidden email]>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


From standarisation and a common approach standpoint, forcing all plugins to use Jira would be reasonable if not for:
- stability problems
- maintenance problems (it is not updated frequently enough imo)
- lack of common process (I don't like for instance that we cannot use fixVersion in the workflow)

All of those could be probably addressed but OTOH, we are also too late with forcing to use Jira as a lot of plugins are already using GH issues and frankly as we discsussed before, I concur with GH Issues being closer to code/repository and easier for maintainers.
So, if each repository/plugin has it's own maintainer and noone from the umbrella organisation, then it should be up to the plugin maintainers to decide what they use - and we already see the tendency here.

--
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/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%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/CAG%3D_Dus4DK%3DiaKZnR6gKGg4Avw1cgm%3D%2Be2gLT4LnC%3DrFbN46eg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Brian Thompson-2
I agree.  I'd love to see Jenkins migrate from Jira to GH.  As a user, if I want to submit an issue to Jenkins, it's a bit cumbersome to create an additional account for Atlassian just so that I can create a ticket.  However, it's highly likely that I already have a GH account and have even browsed the codebase a bit or cloned the repo myself from GH.  So having the issues right where I am makes my life easier.

On Wed, Jun 10, 2020 at 7:57 PM 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
personally, as someone who replies to emails/tickets on my phone a lot, I'd love to see everything migrated from self hosted jira to github, and have one less item that the infra team needs to manage. Plus easier for people to report bugs since they don't need to make an ldap account first

On Wed, Jun 10, 2020 at 7:06 AM Radosław Antoniuk <[hidden email]> wrote:
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <[hidden email]>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


From standarisation and a common approach standpoint, forcing all plugins to use Jira would be reasonable if not for:
- stability problems
- maintenance problems (it is not updated frequently enough imo)
- lack of common process (I don't like for instance that we cannot use fixVersion in the workflow)

All of those could be probably addressed but OTOH, we are also too late with forcing to use Jira as a lot of plugins are already using GH issues and frankly as we discsussed before, I concur with GH Issues being closer to code/repository and easier for maintainers.
So, if each repository/plugin has it's own maintainer and noone from the umbrella organisation, then it should be up to the plugin maintainers to decide what they use - and we already see the tendency here.

--
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/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%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/CAG%3D_Dus4DK%3DiaKZnR6gKGg4Avw1cgm%3D%2Be2gLT4LnC%3DrFbN46eg%40mail.gmail.com.


--
Best regards,

Brian

--
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/CAHY5bT_R%3DMUhFuSjQTMcLiK%2B46tnLXKx%3DV8i40TRC-%2BncRJi%3Dw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

slide
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

On Wed, Jun 10, 2020, 19:49 Brian Thompson <[hidden email]> wrote:
I agree.  I'd love to see Jenkins migrate from Jira to GH.  As a user, if I want to submit an issue to Jenkins, it's a bit cumbersome to create an additional account for Atlassian just so that I can create a ticket.  However, it's highly likely that I already have a GH account and have even browsed the codebase a bit or cloned the repo myself from GH.  So having the issues right where I am makes my life easier.

On Wed, Jun 10, 2020 at 7:57 PM 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
personally, as someone who replies to emails/tickets on my phone a lot, I'd love to see everything migrated from self hosted jira to github, and have one less item that the infra team needs to manage. Plus easier for people to report bugs since they don't need to make an ldap account first

On Wed, Jun 10, 2020 at 7:06 AM Radosław Antoniuk <[hidden email]> wrote:
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <[hidden email]>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


From standarisation and a common approach standpoint, forcing all plugins to use Jira would be reasonable if not for:
- stability problems
- maintenance problems (it is not updated frequently enough imo)
- lack of common process (I don't like for instance that we cannot use fixVersion in the workflow)

All of those could be probably addressed but OTOH, we are also too late with forcing to use Jira as a lot of plugins are already using GH issues and frankly as we discsussed before, I concur with GH Issues being closer to code/repository and easier for maintainers.
So, if each repository/plugin has it's own maintainer and noone from the umbrella organisation, then it should be up to the plugin maintainers to decide what they use - and we already see the tendency here.

--
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/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%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/CAG%3D_Dus4DK%3DiaKZnR6gKGg4Avw1cgm%3D%2Be2gLT4LnC%3DrFbN46eg%40mail.gmail.com.


--
Best regards,

Brian

--
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/CAHY5bT_R%3DMUhFuSjQTMcLiK%2B46tnLXKx%3DV8i40TRC-%2BncRJi%3Dw%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/CAPiUgVcTDfyEktC3N0AVBy_mOMU6U86UkWHD6SvkCCcbQ8KS%3DQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
Wouldn't you either transfer it or ask them to re-file with the correct component?
Same as with Jira?

I doubt issues filed with the wrong component in Jira are ever seen by the right people either.

Thanks
Tim

On Thu, 11 Jun 2020 at 15:33, Slide <[hidden email]> wrote:
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

On Wed, Jun 10, 2020, 19:49 Brian Thompson <[hidden email]> wrote:
I agree.  I'd love to see Jenkins migrate from Jira to GH.  As a user, if I want to submit an issue to Jenkins, it's a bit cumbersome to create an additional account for Atlassian just so that I can create a ticket.  However, it's highly likely that I already have a GH account and have even browsed the codebase a bit or cloned the repo myself from GH.  So having the issues right where I am makes my life easier.

On Wed, Jun 10, 2020 at 7:57 PM 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
personally, as someone who replies to emails/tickets on my phone a lot, I'd love to see everything migrated from self hosted jira to github, and have one less item that the infra team needs to manage. Plus easier for people to report bugs since they don't need to make an ldap account first

On Wed, Jun 10, 2020 at 7:06 AM Radosław Antoniuk <[hidden email]> wrote:
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <[hidden email]>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


From standarisation and a common approach standpoint, forcing all plugins to use Jira would be reasonable if not for:
- stability problems
- maintenance problems (it is not updated frequently enough imo)
- lack of common process (I don't like for instance that we cannot use fixVersion in the workflow)

All of those could be probably addressed but OTOH, we are also too late with forcing to use Jira as a lot of plugins are already using GH issues and frankly as we discsussed before, I concur with GH Issues being closer to code/repository and easier for maintainers.
So, if each repository/plugin has it's own maintainer and noone from the umbrella organisation, then it should be up to the plugin maintainers to decide what they use - and we already see the tendency here.

--
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/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%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/CAG%3D_Dus4DK%3DiaKZnR6gKGg4Avw1cgm%3D%2Be2gLT4LnC%3DrFbN46eg%40mail.gmail.com.


--
Best regards,

Brian

--
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/CAHY5bT_R%3DMUhFuSjQTMcLiK%2B46tnLXKx%3DV8i40TRC-%2BncRJi%3Dw%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/CAPiUgVcTDfyEktC3N0AVBy_mOMU6U86UkWHD6SvkCCcbQ8KS%3DQ%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-3Bid3uZnU0jP9rZwK%3D11C8bYpNBRDBdc11EvPGa_VcsVkUg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Jeff Thompson
In reply to this post by slide
On 6/11/20 8:32 AM, Slide wrote:
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

These are the big issues with moving away from a system-wide tracker to individual trackers. Jenkins is a system of interacting components and issues may involve multiple.

As Remoting maintainer I see this frequently. Someone may submit an issue against Remoting, but often it has to do with a plugin and just shows up in Remoting. Eventually Remoting is removed from the components list and the correct one is assigned. Then the maintainer of that one has notification. Sometimes it helps define the problem. Someone submits the issue against Remoting and a plugin that might show up in the stack trace or messages. I look at it and have no idea, but the maintainer of the other component quickly identifies it.

Sometimes something is submitted against core but we decide it needs to be fixed somewhere else. Or vice versa.

And then there are security issues. We manage security issues as a Jenkins system.

If we switch to tracking issues solely by individual component we're going to lose track of a lot of things. Well, a lot more than we already do.

Jeff

--
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/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Jesse Glick-4
On Thu, Jun 11, 2020 at 11:26 AM Jeff Thompson <[hidden email]> wrote:
> Jenkins is a system of interacting components and issues may involve multiple.

Every time I have worked with a Jira issue with multiple components, I
have wound up regretting the resulting confusion. It gets marked fixed
by one person due to a fix in one repository, but something else still
needs to be done in another repository, etc. So long as a repository
corresponds to an actual artifact and an actual version number, it is
advisable to just have one issue per repository and link them
textually as needed. (Once the code associated with the issue is
clear! Before then, you can just transfer an issue.)

While I generally find GH issues far more comfortable to work with,
the search options are terrible compared to JQL.

--
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/CANfRfr0ebVvD%2BVbu-38SnEZ5zWhEVrRgCOuDJ%3D-mNuh_QJ3DXA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Ulli Hafner
In reply to this post by Jeff Thompson
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 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).

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. 

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).  

Am 11.06.2020 um 17:26 schrieb Jeff Thompson <[hidden email]>:

On 6/11/20 8:32 AM, Slide wrote:
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

These are the big issues with moving away from a system-wide tracker to individual trackers. Jenkins is a system of interacting components and issues may involve multiple.

As Remoting maintainer I see this frequently. Someone may submit an issue against Remoting, but often it has to do with a plugin and just shows up in Remoting. Eventually Remoting is removed from the components list and the correct one is assigned. Then the maintainer of that one has notification. Sometimes it helps define the problem. Someone submits the issue against Remoting and a plugin that might show up in the stack trace or messages. I look at it and have no idea, but the maintainer of the other component quickly identifies it.

Sometimes something is submitted against core but we decide it needs to be fixed somewhere else. Or vice versa.

And then there are security issues. We manage security issues as a Jenkins system.

If we switch to tracking issues solely by individual component we're going to lose track of a lot of things. Well, a lot more than we already do.

Jeff


--
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/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.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/E40E03EE-1538-487E-A5AF-D1162E5D4B14%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

James Nord-2
I agree with Ulli's statements.

There seems to be comments that our hosted Jira is sluggish or hard to maintain.  I've asked before but why can,t the cloud version be an option?
we should be able to spin up a stateless SAML to LDAP integration for Jira Cloud with much less effort than continuing to patch/maintain our own Jira (and pay for the infra)?
maybe it's a license thing, in which case could we approach atlassian and ask?
I think many project are not wanting to use GH issues and so it seems that improving Jira would make things better for everyone even if it is not what some would desire in the end.

--
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/b9896b3e-89c6-4391-850c-68437d8820a4o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

slide
The issue with the cloud version is that it is not compatible with our LDAP (at least that is what I believe Olivier said last time). 

On Thu, Jun 11, 2020 at 2:28 PM James Nord <[hidden email]> wrote:
I agree with Ulli's statements.

There seems to be comments that our hosted Jira is sluggish or hard to maintain.  I've asked before but why can,t the cloud version be an option?
we should be able to spin up a stateless SAML to LDAP integration for Jira Cloud with much less effort than continuing to patch/maintain our own Jira (and pay for the infra)?
maybe it's a license thing, in which case could we approach atlassian and ask?
I think many project are not wanting to use GH issues and so it seems that improving Jira would make things better for everyone even if it is not what some would desire in the end.

--
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/b9896b3e-89c6-4391-850c-68437d8820a4o%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/CAPiUgVeJvRM5LrrPwwS93pyiO38iSWpkYEDHna3_1E%2BaB1JNRw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
According to https://issues.jenkins-ci.org/browse/INFRA-2010?jql=text%20~%20%22jira%22%20and%20text%20~%20%22ldap%22%20and%20text%20~%20%22cloud%22 there's also an issue that you can't import only 5k users total, and we have more than 100k users.

https://confluence.atlassian.com/cloud/saml-single-sign-on-943953302.html says saml is an option, and keycloak hooks up to ldap pretty easily and provides saml, so it might be doable.

Personally i want consistency, if some is in jira and some in github, its frustrating when people ask how to report things

On Thu, Jun 11, 2020 at 2:30 PM Slide <[hidden email]> wrote:
The issue with the cloud version is that it is not compatible with our LDAP (at least that is what I believe Olivier said last time). 

On Thu, Jun 11, 2020 at 2:28 PM James Nord <[hidden email]> wrote:
I agree with Ulli's statements.

There seems to be comments that our hosted Jira is sluggish or hard to maintain.  I've asked before but why can,t the cloud version be an option?
we should be able to spin up a stateless SAML to LDAP integration for Jira Cloud with much less effort than continuing to patch/maintain our own Jira (and pay for the infra)?
maybe it's a license thing, in which case could we approach atlassian and ask?
I think many project are not wanting to use GH issues and so it seems that improving Jira would make things better for everyone even if it is not what some would desire in the end.

--
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/b9896b3e-89c6-4391-850c-68437d8820a4o%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/CAPiUgVeJvRM5LrrPwwS93pyiO38iSWpkYEDHna3_1E%2BaB1JNRw%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/CAG%3D_DuukW6C%3DyVfjstGDqxrbMtgYvzpCn1_vGdrkSJc9FypCgA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

domi@fortysix.ch
In reply to this post by Ulli Hafner
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 :(
/Domi

On 11 Jun 2020, at 19:25, Ullrich Hafner <[hidden email]> 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 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).

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. 

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).  

Am 11.06.2020 um 17:26 schrieb Jeff Thompson <[hidden email]>:

On 6/11/20 8:32 AM, Slide wrote:
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

These are the big issues with moving away from a system-wide tracker to individual trackers. Jenkins is a system of interacting components and issues may involve multiple.

As Remoting maintainer I see this frequently. Someone may submit an issue against Remoting, but often it has to do with a plugin and just shows up in Remoting. Eventually Remoting is removed from the components list and the correct one is assigned. Then the maintainer of that one has notification. Sometimes it helps define the problem. Someone submits the issue against Remoting and a plugin that might show up in the stack trace or messages. I look at it and have no idea, but the maintainer of the other component quickly identifies it.

Sometimes something is submitted against core but we decide it needs to be fixed somewhere else. Or vice versa.

And then there are security issues. We manage security issues as a Jenkins system.

If we switch to tracking issues solely by individual component we're going to lose track of a lot of things. Well, a lot more than we already do.

Jeff


--
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/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.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/E40E03EE-1538-487E-A5AF-D1162E5D4B14%40gmail.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/0F68D3FD-1616-438A-89FA-6DF459164FF5%40fortysix.ch.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk

On Fri, Jun 12, 2020 at 6:07 AM Dominik Bartholdi <[hidden email]> 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 :(

 
On 11 Jun 2020, at 19:25, Ullrich Hafner <[hidden email]> 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)

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