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

Chris Kilding
While there are differences of opinion on the issue *storage* problem (ie do we store our issues in Jira or GitHub), there seems to be common ground on solving the *access* problem for users that report issues.

If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.

I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

This suggests a couple of questions:

1. Can such a GitHub connector be installed on the Jira we’ve already got?
2. If not, can anyone provide a (vague) timescale for getting things into Jira Cloud and enabling the connector? (I appreciate this is probably a long job.)

Chris

On Sat, 8 Feb 2020, at 2:14 PM, Daniel Beck wrote:


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


Attachments:
  • image.png

--
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/fa60cafb-7b5f-406b-a14c-8467015e4f9f%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
As far as I know for jira cloud the only log in options are atlassian account or SAML (may be premium option, can’t find docs for it)


On Sat, 8 Feb 2020 at 23:54, Chris Kilding <[hidden email]> wrote:
While there are differences of opinion on the issue *storage* problem (ie do we store our issues in Jira or GitHub), there seems to be common ground on solving the *access* problem for users that report issues.

If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.

I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

This suggests a couple of questions:

1. Can such a GitHub connector be installed on the Jira we’ve already got?
2. If not, can anyone provide a (vague) timescale for getting things into Jira Cloud and enabling the connector? (I appreciate this is probably a long job.)

Chris

On Sat, 8 Feb 2020, at 2:14 PM, Daniel Beck wrote:


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


Attachments:
  • image.png

--
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/fa60cafb-7b5f-406b-a14c-8467015e4f9f%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-3BicWcY92OGr8sJcWUMG4UhSqarAu7Y_DNNCw-B9M1az_nw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck
In reply to this post by Chris Kilding


> On 9. Feb 2020, at 00:53, Chris Kilding <[hidden email]> wrote:
>
> there seems to be common ground on solving the *access* problem for users that report issues.
>
> If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.
>
> I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

So far I've never felt like we needed more bugs reported, or features requested. We collectively suck at responding and fixing anyway. What's the point of making it easier to have one's issue ignored?

(To be clear: This is not a good situation. But it seems we should fix _that_ first.)

Also, I haven't seen any proof so far for the assumption that everyone has a GitHub account anyway. That seems like a very OSS developer centric view of the world.

--
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/1BD227AC-FDF8-4FAC-ACE8-D8F92CF806AF%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Olblak-2
Let's bring back the infrastructure point of view into the discussion

Jira to Jira Cloud INFRA-2010
If someone is willing to do more experimentation with it, be my guest but for what I understand contributors require an Atlassian account to connect on Jira cloud
so no GitHub SSO, neither LDAP auth and max 5000 users, which also means regular old accounts and spammers cleanup.
For the context, today we have 104626 accounts on Jira
-> In the current state, because of the identity management, I am not very optimistic about migrating all projects to Jira cloud, 

Remaining on issues.jenkins-ci.orb, [INFRA-2262], 
No integration between Jira and Github as it uses Github API and we hit the limit very quickly so we had to disable it
The second element, excepted Tyler and me, nobody "maintains" it and unfortunately, we can only accept trusted people to work on issues.jenkins-ci.org as it contains the security work.
so I don't see how we can keep maintaining it unless we have someone dedicated to Jira who upgrade Jira every several weeks and also work on performance
-> In the current state, because of the maintaining effort, I am seriously not optimistic to stay on issues.jenkins-ci.org

Moving to GitHub issues
Identity management and maintaining effort is solved, but some extra work is needed to migrate Jira tickets to Github issues. 
And personally I am a bit concerned about managing the all Jenkins project on GitHub for multiple reasons but they are largely compensated by not having to maintain a ticketing system. I also think that another concern that I have is because I am not as experienced as I am with Jira which is why I am willing to give it a try for a small project like the hosting project. but if we do that, we need to be clear on an end date for the experimentation.

Maybe someone has another proposition like neither Github or Jira

Cheers


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

On Sun, Feb 9, 2020, at 6:24 PM, Daniel Beck wrote:


> > On 9. Feb 2020, at 00:53, Chris Kilding <[hidden email]> wrote:
> > 
> > there seems to be common ground on solving the *access* problem for users that report issues.
> > 
> > If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.
> > 
> > I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

> So far I've never felt like we needed more bugs reported, or features 
> requested. We collectively suck at responding and fixing anyway. What's 
> the point of making it easier to have one's issue ignored?

> (To be clear: This is not a good situation. But it seems we should fix 
> _that_ first.)

> Also, I haven't seen any proof so far for the assumption that everyone 
> has a GitHub account anyway. That seems like a very OSS developer 
> centric view of the world.

> -- 
> 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/1BD227AC-FDF8-4FAC-ACE8-D8F92CF806AF%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/10a48587-a3c0-48f7-a0d5-f76cd5495a9b%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Ulli Hafner


Am 10.02.2020 um 09:50 schrieb Olblak <[hidden email]>:

Let's bring back the infrastructure point of view into the discussion

Jira to Jira Cloud INFRA-2010
If someone is willing to do more experimentation with it, be my guest but for what I understand contributors require an Atlassian account to connect on Jira cloud
so no GitHub SSO, neither LDAP auth and max 5000 users, which also means regular old accounts and spammers cleanup.
For the context, today we have 104626 accounts on Jira
-> In the current state, because of the identity management, I am not very optimistic about migrating all projects to Jira cloud, 


Do we still need our LDAP if we migrate Jira to the cloud? What other services are using our LDAP? (Can ci.jenkins use GitHub Authentication?)

Remaining on issues.jenkins-ci.orb, [INFRA-2262], 
No integration between Jira and Github as it uses Github API and we hit the limit very quickly so we had to disable it 
The second element, excepted Tyler and me, nobody "maintains" it and unfortunately, we can only accept trusted people to work on issues.jenkins-ci.org as it contains the security work.
so I don't see how we can keep maintaining it unless we have someone dedicated to Jira who upgrade Jira every several weeks and also work on performance
-> In the current state, because of the maintaining effort, I am seriously not optimistic to stay on issues.jenkins-ci.org

Moving to GitHub issues
Identity management and maintaining effort is solved, but some extra work is needed to migrate Jira tickets to Github issues. 
And personally I am a bit concerned about managing the all Jenkins project on GitHub for multiple reasons but they are largely compensated by not having to maintain a ticketing system. I also think that another concern that I have is because I am not as experienced as I am with Jira which is why I am willing to give it a try for a small project like the hosting project. but if we do that, we need to be clear on an end date for the experimentation.

Maybe someone has another proposition like neither Github or Jira 

Cheers


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

On Sun, Feb 9, 2020, at 6:24 PM, Daniel Beck wrote:


> > On 9. Feb 2020, at 00:53, Chris Kilding <[hidden email]> wrote:
> > 
> > there seems to be common ground on solving the *access* problem for users that report issues.
> > 
> > If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.
> > 
> > I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

> So far I've never felt like we needed more bugs reported, or features 
> requested. We collectively suck at responding and fixing anyway. What's 
> the point of making it easier to have one's issue ignored?

> (To be clear: This is not a good situation. But it seems we should fix 
> _that_ first.)

> Also, I haven't seen any proof so far for the assumption that everyone 
> has a GitHub account anyway. That seems like a very OSS developer 
> centric view of the world.

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

-- 
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/10a48587-a3c0-48f7-a0d5-f76cd5495a9b%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/8B335261-4289-4447-9285-CB412E513A5A%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck
In reply to this post by Olblak-2


> On 10. Feb 2020, at 09:50, Olblak <[hidden email]> wrote:
>
> The second element, excepted Tyler and me, nobody "maintains" it and unfortunately, we can only accept trusted people to work on issues.jenkins-ci.org as it contains the security work.

Any option that removes issues.j.o entirely will need to have a plan that includes a complete and tamper-proof mapping of every plugin maintainer's Jenkins/Artifactory account to the future issue tracker account, including all past maintainers.

Right now, I assign issues to whoever is listed in permission YAML files. How would this work in the future?

--
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/598CAD95-CA39-4A7D-87F3-67B7460146E8%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 10. Feb 2020, at 10:08, Ullrich Hafner <[hidden email]> wrote:
>
> What other services are using our LDAP?

Account app (duh), Wiki (sort of going away very slowly), all our Jenkins instances (ci, trusted.ci, and cert.ci), and Artifactory (this is why you use your Jenkins user name in https://github.com/jenkins-infra/repository-permissions-updater/ )

Could we exclude LDAP from this thread? It's already a mess, we went from "Wouldn't it be nice if we had better support for GH issues in the hosting process" to "Let's shut down Jira".

--
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/37A68695-188E-499A-A7AB-F9604673E4F4%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Olblak-2
What other services are using our LDAP?

They are so many places where we use ldap that we won't get rid of it easily, especially in the infra part, and I am really not concerned about it, as it's really easy to maintain

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

On Mon, Feb 10, 2020, at 10:15 AM, Daniel Beck wrote:


> > On 10. Feb 2020, at 10:08, Ullrich Hafner <[hidden email]> wrote:
> > 
> > What other services are using our LDAP?

> Account app (duh), Wiki (sort of going away very slowly), all our 
> Jenkins instances (ci, trusted.ci, and cert.ci), and Artifactory (this 
> is why you use your Jenkins user name in 
> https://github.com/jenkins-infra/repository-permissions-updater/ )

> Could we exclude LDAP from this thread? It's already a mess, we went 
> from "Wouldn't it be nice if we had better support for GH issues in the 
> hosting process" to "Let's shut down Jira".

> -- 
> 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/37A68695-188E-499A-A7AB-F9604673E4F4%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/e9dbeace-b7d7-495c-9e85-c90b71727b2a%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Ulli Hafner
In reply to this post by Daniel Beck
Ok, then let us summarize the side track:
We cannot and do not want to drop Jira because it is used in a lot of places and the features are superior to GitHub issues. We can improve performance and usability of Jira if we would deploy a more recent version of Jira (or use the cloud version).

Then I am more then before -1 on opening support for GitHub issues, since our users should simply use only one tool to report issues for Jenkins and its plugins. (And for me as developer it makes cross-component issue handling also simpler if there is only one tool to use.)

> Am 10.02.2020 um 10:15 schrieb Daniel Beck <[hidden email]>:
>
>
>
>> On 10. Feb 2020, at 10:08, Ullrich Hafner <[hidden email]> wrote:
>>
>> What other services are using our LDAP?
>
> Account app (duh), Wiki (sort of going away very slowly), all our Jenkins instances (ci, trusted.ci, and cert.ci), and Artifactory (this is why you use your Jenkins user name in https://github.com/jenkins-infra/repository-permissions-updater/ )
>
> Could we exclude LDAP from this thread? It's already a mess, we went from "Wouldn't it be nice if we had better support for GH issues in the hosting process" to "Let's shut down Jira".
>
> --
> 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/37A68695-188E-499A-A7AB-F9604673E4F4%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/630057BF-6723-41B8-8DD2-C3BED62176F4%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
Who is going to update it? And what benefit does that bring?

And moving to the cloud version brings less features, a new account type everyone has to sign up to, but less maintenance

On Mon, 10 Feb 2020 at 10:28, Ullrich Hafner <[hidden email]> wrote:
Ok, then let us summarize the side track:
We cannot and do not want to drop Jira because it is used in a lot of places and the features are superior to GitHub issues. We can improve performance and usability of Jira if we would deploy a more recent version of Jira (or use the cloud version).

Then I am more then before -1 on opening support for GitHub issues, since our users should simply use only one tool to report issues for Jenkins and its plugins. (And for me as developer it makes cross-component issue handling also simpler if there is only one tool to use.)

> Am 10.02.2020 um 10:15 schrieb Daniel Beck <[hidden email]>:
>
>
>
>> On 10. Feb 2020, at 10:08, Ullrich Hafner <[hidden email]> wrote:
>>
>> What other services are using our LDAP?
>
> Account app (duh), Wiki (sort of going away very slowly), all our Jenkins instances (ci, trusted.ci, and cert.ci), and Artifactory (this is why you use your Jenkins user name in https://github.com/jenkins-infra/repository-permissions-updater/ )
>
> Could we exclude LDAP from this thread? It's already a mess, we went from "Wouldn't it be nice if we had better support for GH issues in the hosting process" to "Let's shut down Jira".
>
> --
> 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/37A68695-188E-499A-A7AB-F9604673E4F4%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/630057BF-6723-41B8-8DD2-C3BED62176F4%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/CAH-3BiehijtntYhN3xqRj85%3Dw3M7BnEwHh%3DQXZ1fetXb8eX3yw%40mail.gmail.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:
>
> GitHub issues use is growing in the ecosystem, many plugins are now using it,

Given the discussion, I now seriously doubt that this would be beneficial over the long-term to the project.

Not because the proposal is a bad idea on its own (it's not), but based on the answers so far, it looks to me like some want Jira gone completely, and want to use this proposal as a back door to get rid of issues.j.o without an adequate replacement in the name of "unifying" where issues are tracked. This isn't even perhaps an individual contributor's position, but between "I want GH issues / I don't want Jira" and "Multiple issue trackers are bad", this is where we seem to be heading.

If we go with this approach and similar ones (for example the better plugin metadata that allows having an issue tracker link directly in Jenkins plugin manager), we need to be committed to continue having different issue trackers for a while. Making it easier for users who maintainers want to use GH issues shouldn't mean we'll ignore others' preference for Jira.

And if Jira presents significant challenges e.g. to the infra team, which it looks like, I'd be happy to have a separate, open discussion about the continued use of Jira. I resist not because I love it so much (I don't), but because I use it a lot and I simply don't see how my use cases translate elsewhere (GH issues and to a degree Jira Cloud) -- some of which are pretty core to my role as security officer (for example the case from my email from yesterday). But that conversation should be based on a properly defined IEP/JEP looking at all aspects of such a transition, rather than a disjointed set of messages across several channels/threads.

--
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/9BEC892B-EB0F-430C-BD1B-790DDBA6C1D5%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
I'll freely admit I dislike jira, but I think the mix for plugins of using jira and github are very confusing.

I see a major issue, that security issues can't really work in github, since they can't be made private for certain people, which means if you'd have issues for a plugin in both github and jira its a big mess. And I believe only github org admins (or at least someone with write support in both repos) can move issues between repos. Which will make issues getting lost due to the wrong component even worse.

I'm all in favor of non core and non plugins using github to make things more visible, but not for the central project.

And infra has a lot more secrets, so it makes sense to be in jira where things can be managed.

I'm totally in favor of moving to cloud jira instead of hosted jira to reduce maintenance, but that requires a lot of work too.



On Mon, Feb 10, 2020 at 5:44 AM Daniel Beck <[hidden email]> wrote:


> On 2. Feb 2020, at 12:13, Tim Jacomb <[hidden email]> wrote:
>
> GitHub issues use is growing in the ecosystem, many plugins are now using it,

Given the discussion, I now seriously doubt that this would be beneficial over the long-term to the project.

Not because the proposal is a bad idea on its own (it's not), but based on the answers so far, it looks to me like some want Jira gone completely, and want to use this proposal as a back door to get rid of issues.j.o without an adequate replacement in the name of "unifying" where issues are tracked. This isn't even perhaps an individual contributor's position, but between "I want GH issues / I don't want Jira" and "Multiple issue trackers are bad", this is where we seem to be heading.

If we go with this approach and similar ones (for example the better plugin metadata that allows having an issue tracker link directly in Jenkins plugin manager), we need to be committed to continue having different issue trackers for a while. Making it easier for users who maintainers want to use GH issues shouldn't mean we'll ignore others' preference for Jira.

And if Jira presents significant challenges e.g. to the infra team, which it looks like, I'd be happy to have a separate, open discussion about the continued use of Jira. I resist not because I love it so much (I don't), but because I use it a lot and I simply don't see how my use cases translate elsewhere (GH issues and to a degree Jira Cloud) -- some of which are pretty core to my role as security officer (for example the case from my email from yesterday). But that conversation should be based on a properly defined IEP/JEP looking at all aspects of such a transition, rather than a disjointed set of messages across several channels/threads.

--
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/9BEC892B-EB0F-430C-BD1B-790DDBA6C1D5%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_DutrL%3D1wKeVhRNATGL_37OSHEfn8aw2hWJoc2dPsW3SQaA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
I feel like we can work something out for the security project, possibly there’s a better tool for it...

I don’t think it’ll work easily in the cloud version either

For transferring you need at least write and possibly admin on both ends to use the GitHub ui for it, but there’s a GitHub app for it that looks like it would do what we need: 

Not sure how infra having secrets makes it a better fit for jira?

On Tue, 11 Feb 2020 at 00:57, 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
I'll freely admit I dislike jira, but I think the mix for plugins of using jira and github are very confusing.

I see a major issue, that security issues can't really work in github, since they can't be made private for certain people, which means if you'd have issues for a plugin in both github and jira its a big mess. And I believe only github org admins (or at least someone with write support in both repos) can move issues between repos. Which will make issues getting lost due to the wrong component even worse.

I'm all in favor of non core and non plugins using github to make things more visible, but not for the central project.

And infra has a lot more secrets, so it makes sense to be in jira where things can be managed.

I'm totally in favor of moving to cloud jira instead of hosted jira to reduce maintenance, but that requires a lot of work too.



On Mon, Feb 10, 2020 at 5:44 AM Daniel Beck <[hidden email]> wrote:


> On 2. Feb 2020, at 12:13, Tim Jacomb <[hidden email]> wrote:
>
> GitHub issues use is growing in the ecosystem, many plugins are now using it,

Given the discussion, I now seriously doubt that this would be beneficial over the long-term to the project.

Not because the proposal is a bad idea on its own (it's not), but based on the answers so far, it looks to me like some want Jira gone completely, and want to use this proposal as a back door to get rid of issues.j.o without an adequate replacement in the name of "unifying" where issues are tracked. This isn't even perhaps an individual contributor's position, but between "I want GH issues / I don't want Jira" and "Multiple issue trackers are bad", this is where we seem to be heading.

If we go with this approach and similar ones (for example the better plugin metadata that allows having an issue tracker link directly in Jenkins plugin manager), we need to be committed to continue having different issue trackers for a while. Making it easier for users who maintainers want to use GH issues shouldn't mean we'll ignore others' preference for Jira.

And if Jira presents significant challenges e.g. to the infra team, which it looks like, I'd be happy to have a separate, open discussion about the continued use of Jira. I resist not because I love it so much (I don't), but because I use it a lot and I simply don't see how my use cases translate elsewhere (GH issues and to a degree Jira Cloud) -- some of which are pretty core to my role as security officer (for example the case from my email from yesterday). But that conversation should be based on a properly defined IEP/JEP looking at all aspects of such a transition, rather than a disjointed set of messages across several channels/threads.

--
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/9BEC892B-EB0F-430C-BD1B-790DDBA6C1D5%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_DutrL%3D1wKeVhRNATGL_37OSHEfn8aw2hWJoc2dPsW3SQaA%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-3BicbvO%3DJdC6bOKTMasd--b6X0EkFQt-ss1HSmH9wx1eMsg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Olblak-2
I am happy that we start this discussion early enough before the current Jira version becomes at the end of life.
It's a topic important enough to have as much feedback as possible but also whatever we decide we won't have support from 100% of the contributors otherwise we wouldn't have this long thread.

Whatever we decide, I think we should try to apply the same process for all the tickets.

If someone is interested to help to work on a JEP to summarize all the pros/cons here and identify possible solutions, that would be awesome and then I suggest that once done, we organize a vote using the Condorcet tool.


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


On Tue, Feb 11, 2020, at 8:11 AM, Tim Jacomb wrote:
I feel like we can work something out for the security project, possibly there’s a better tool for it...

I don’t think it’ll work easily in the cloud version either

For transferring you need at least write and possibly admin on both ends to use the GitHub ui for it, but there’s a GitHub app for it that looks like it would do what we need: 

Not sure how infra having secrets makes it a better fit for jira?

On Tue, 11 Feb 2020 at 00:57, 'Gavin Mogan' via Jenkins Developers <[hidden email]> wrote:
I'll freely admit I dislike jira, but I think the mix for plugins of using jira and github are very confusing.

I see a major issue, that security issues can't really work in github, since they can't be made private for certain people, which means if you'd have issues for a plugin in both github and jira its a big mess. And I believe only github org admins (or at least someone with write support in both repos) can move issues between repos. Which will make issues getting lost due to the wrong component even worse.

I'm all in favor of non core and non plugins using github to make things more visible, but not for the central project.

And infra has a lot more secrets, so it makes sense to be in jira where things can be managed.

I'm totally in favor of moving to cloud jira instead of hosted jira to reduce maintenance, but that requires a lot of work too.



On Mon, Feb 10, 2020 at 5:44 AM Daniel Beck <[hidden email]> wrote:


> On 2. Feb 2020, at 12:13, Tim Jacomb <[hidden email]> wrote:
>
> GitHub issues use is growing in the ecosystem, many plugins are now using it,

Given the discussion, I now seriously doubt that this would be beneficial over the long-term to the project.

Not because the proposal is a bad idea on its own (it's not), but based on the answers so far, it looks to me like some want Jira gone completely, and want to use this proposal as a back door to get rid of issues.j.o without an adequate replacement in the name of "unifying" where issues are tracked. This isn't even perhaps an individual contributor's position, but between "I want GH issues / I don't want Jira" and "Multiple issue trackers are bad", this is where we seem to be heading.

If we go with this approach and similar ones (for example the better plugin metadata that allows having an issue tracker link directly in Jenkins plugin manager), we need to be committed to continue having different issue trackers for a while. Making it easier for users who maintainers want to use GH issues shouldn't mean we'll ignore others' preference for Jira.

And if Jira presents significant challenges e.g. to the infra team, which it looks like, I'd be happy to have a separate, open discussion about the continued use of Jira. I resist not because I love it so much (I don't), but because I use it a lot and I simply don't see how my use cases translate elsewhere (GH issues and to a degree Jira Cloud) -- some of which are pretty core to my role as security officer (for example the case from my email from yesterday). But that conversation should be based on a properly defined IEP/JEP looking at all aspects of such a transition, rather than a disjointed set of messages across several channels/threads.

--
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/e8087e4e-2f6f-4997-b650-597cf565b1ce%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 11. Feb 2020, at 08:11, Tim Jacomb <[hidden email]> wrote:
>
> I feel like we can work something out for the security project, possibly there’s a better tool for it...
>
> I don’t think it’ll work easily in the cloud version either

Since it seems like we've managed to finally really derail this thread, I'll follow up:

The major obstacle as I see it is the mapping of users. This applies to every alternative not backed by our LDAP.

We need something that every maintainer inherently has access to, ideally even used before; and a tamper-proof & complete mapping between those accounts and the accounts in permission YAML files (which we use as reference to determine who even is a maintainer) that does not require any actions by hundreds of current maintainers.

Right now, we get all of this for free: LDAP account creation creates Jira account; plugin hosting requests and most plugins' issues are tracked in Jira; both systems share the same user name.

We already have trouble with some Jira accounts having outdated notification email addresses in Jira, and need to go some lengths to contact these maintainers, and doing it via email typically means I am then the SPOF for any direct email responses. Doing something similar for every issue simply won't scale.

--
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/66B4FB4F-9BDF-4C87-9E01-14C1F6A0804E%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Jesse Glick-4
Since the thread is indeed pretty well derailed by now,

On Fri, Feb 14, 2020 at 9:17 AM Daniel Beck <[hidden email]> wrote:
> The major obstacle as I see it is the mapping of users. This applies to every alternative not backed by our LDAP.

Right. It would be great to switch to GitHub SSO, avoiding the
confusion between oleg-nenashev vs. oleg_nenashev and so on, and
ending a bunch of issues such as old email aliases. JIRA and
Artifactory would need to support this connector. (So few people have
special permissions on ci.jenkins.io that this seems like a minor
issue.) “Mapping” would boil down to ensuring that any active
maintainers have gone to https://accounts.jenkins.io/myself/ to set
their GitHub ID prior to the switchover.

--
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/CANfRfr28BHfsRwOZsx5w-_qzu2%2BoVOGaDQ0LC3rd8UMXTgavSQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Daniel Beck-2


On Fri, Feb 14, 2020 at 4:59 PM Jesse Glick <[hidden email]> wrote:

Right. It would be great to switch to GitHub SSO, avoiding the
confusion between oleg-nenashev vs. oleg_nenashev and so on, and
ending a bunch of issues such as old email aliases. JIRA and
Artifactory would need to support this connector. (So few people have
special permissions on ci.jenkins.io that this seems like a minor
issue.) “Mapping” would boil down to ensuring that any active
maintainers have gone to https://accounts.jenkins.io/myself/ to set
their GitHub ID prior to the switchover.

That is neither complete (as it requires user action), nor a tamper-proof (AFAIR, nothing ensures you're not lying, or even have a typo).

We regularly contact maintainers who haven't released anything in more than a year or two about security issues. So this mapping would _at least_ have to be enforced 1-2 years before we switch over to a Jira alternative.

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

Re: GitHub issues option in HOSTING

Radosław Antoniuk
I would like to vote +1 for GitHub Issues. 

I tried migration via the API for jira plugin and the only thing that we would lose is the original reporter (it would be noted in the comment but not the issue creator) - I think that this can be lived with.
See https://github.com/warden/jira-plugin/issues for examples (those were all automated via API).

With the fact that we're not using fixVersion field and release process/board in JIRA (I don't think we need it TBH), I think that GH Issues would be more than enough.
Additionally:
- we could use GH Actions for automated label management, releases etc...
- the users to use GH SSO only and not create special account in Jenkins
- we lose performance problems with JIRA infra
- we have a single and _automated_ code-to-issue linking on code-level even

 

--
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/94e85849-653a-4789-92a3-d84a7ca3e2ac%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
That's cool Radek, was this what you used to migrate them? https://github.com/parcelLab/jira-to-github

Or something else?

On Wed, 25 Mar 2020 at 16:27, Radek Antoniuk <[hidden email]> wrote:
I would like to vote +1 for GitHub Issues. 

I tried migration via the API for jira plugin and the only thing that we would lose is the original reporter (it would be noted in the comment but not the issue creator) - I think that this can be lived with.
See https://github.com/warden/jira-plugin/issues for examples (those were all automated via API).

With the fact that we're not using fixVersion field and release process/board in JIRA (I don't think we need it TBH), I think that GH Issues would be more than enough.
Additionally:
- we could use GH Actions for automated label management, releases etc...
- the users to use GH SSO only and not create special account in Jenkins
- we lose performance problems with JIRA infra
- we have a single and _automated_ code-to-issue linking on code-level even

 

--
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/94e85849-653a-4789-92a3-d84a7ca3e2ac%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/CAH-3BieGFRtA9YKg_yLPE9N06%2BW2TTLz7XJJ%2B7swmyrC65B4sw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk
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.
12345