Hi
GitHub issues use is growing in the ecosystem, many plugins are now using it,
Some benefits from my experience in using it:
Easy subscription to issues / pull requests for repositories I maintain / co-maintain
Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
Some repositories that are using them:
https://github.com/jenkinsci/configuration-as-code-plugin, https://github.com/jenkinsci/slack-plugin,
https://github.com/jenkinsci/google-compute-engine-plugin
And many more...
I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:
Delete issues support - for security fixes, GitHub now supports this
Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.
Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1 (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).
I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.
Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.
I would also suggest that we add some text to the Component field that says:
‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.
Any feedback or questions?
Thanks
Tim
Regarding the implementation, my proposal would be to firstly add explicit issue tracker links on the plugin site. Maven metadata already supports it, we just need to expose it in the update center.
Then we could, for example, keep components and use a Jira bot when an issue is misreported.
Just removing a component will have limited impact, because many components are often not reported to a right component anyway (triage is needed, or users just report it wrongly). Removing components is likely to encourage people to take another random component or _unsorted
Easy subscription to issues / pull requests for repositories I maintain / co-maintain
Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.
Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7f2ffee6-9a49-475f-afa8-e09628527d0f%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56145d0a-7eb1-4414-ad5b-a7991d8b918d%40www.fastmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie8jJ%2BY_RrFQD%2BJ_qChjdHN7evrjtJ93viavVRKsCaE2A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2S%3D%2BCb-xNpsARz%2BX5U4XapzrfWZ2PSjkKZmft9usk-7g%40mail.gmail.com.
so far we are all talking about the developer experience when interacting with issues. we need to also think of the user experience to Jenkins users too. it kills me every time I need to file an issue and try and work out where it is to be reported and I consider myself knowledgeable about Jenkins and it's plugins.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D8A0D08A-14C9-4082-8262-DF45D210B4A2%40beckweb.net.
create a filter that matches things you want to be notified for.
subscribe to that filter in https://issues.jenkins-ci.org/secure/ManageFilters.jspa
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5073d833-537b-4d84-a52d-d5fed2cb18f0%40googlegroups.com.
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.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLqd%3DLAjBGwxPP5%2BdkTp%2Bof1L0AUetZ5HdLj6Cu%2BZZ86w%40mail.gmail.com.
(replies inline)On Sat, 8 Feb 2020 at 12:13, Daniel Beck <db...@cloudbees.com> wrote:On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> 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?It takes me 9 seconds to open JIRA for it to be interactive.And then I have to log in every single time...
--You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BQsV%3DxJEGMdo1NU%3D5PxiMbE6c8bbMu7SrKmHcC06Fn%3Dg%40mail.gmail.com.Attachments:
- image.png
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fa60cafb-7b5f-406b-a14c-8467015e4f9f%40www.fastmail.com.
Am 10.02.2020 um 09:50 schrieb Olblak <m...@olblak.com>:Let's bring back the infrastructure point of view into the discussionJira to Jira Cloud INFRA-2010If 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 cloudso 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,
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/10a48587-a3c0-48f7-a0d5-f76cd5495a9b%40www.fastmail.com.
What other services are using our LDAP?
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9BEC892B-EB0F-430C-BD1B-790DDBA6C1D5%40beckweb.net.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutrL%3D1wKeVhRNATGL_37OSHEfn8aw2hWJoc2dPsW3SQaA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicbvO%3DJdC6bOKTMasd--b6X0EkFQt-ss1HSmH9wx1eMsg%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/94e85849-653a-4789-92a3-d84a7ca3e2ac%40googlegroups.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWjopjvpX%2B_oRKZ%2BW6PCsDaJj5NpUtRnj-YdJGY0t1zrdg%40mail.gmail.com.
Am 10.06.2020 um 01:24 schrieb 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com>: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, <radek.a...@gmail.com> 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 jenkinsci-de...@googlegroups.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dutik45JTvY6YznY9qs8Za6Wca%3DaL1BXiKvWaoDcW0RZcw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F6588E45-6D0F-4F85-81C5-7BC83A031862%40gmail.com.
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 jenkinsci-de...@googlegroups.com.
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.
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.
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <radek.a...@gmail.com>: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 jenkinsci-de...@googlegroups.com.
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.
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <radek.a...@gmail.com>: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.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%40mail.gmail.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcTDfyEktC3N0AVBy_mOMU6U86UkWHD6SvkCCcbQ8KS%3DQ%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b9896b3e-89c6-4391-850c-68437d8820a4o%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVeJvRM5LrrPwwS93pyiO38iSWpkYEDHna3_1E%2BaB1JNRw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/E40E03EE-1538-487E-A5AF-D1162E5D4B14%40gmail.com.
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 <ullrich...@gmail.com> wrote:I prefer Jira, from a developer and a user perspective:Developer perspective:- Having the ability to move issues from one component to another is very helpful for me. I don’t see how to do this in GitHub. My plugin uses different components and I want to easily move issues from one component to other components. Also it is very helpful to create issues that affect several components. It makes inter-project communication much simpler.
- I 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).
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWigW42sR%3DRpHVsYx%3DggdWhYA7TbB%2B6NJKry%2B%2BQ8QyaWrQ%40mail.gmail.com.
>
> About consistency, I fully agree, but we are already past that point as the plugins are already mixed up between Jira and GH.
I don’t think that we are past the point yet, just because a couple of plugins managed it to enable GitHub issues. From my understanding the hosting process creates a Jira component and GitHub Issues is disabled for the repository.
Am 18.06.2020 um 19:36 schrieb Jesse Glick <jgl...@cloudbees.com>:stashnotifier-plugin
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/BFAA9E31-30E9-451E-B8D6-A7EA262A1483%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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/EFE72EBF-2AD3-4F12-9879-8A3864CD643D%40gmail.com.
security reports?
currently they are all triaged by the security team so the team can track disclosure deadlines etc.
how would that worknif the plugin is usimg GH issues? (yes I know gh issues can now handle security reports but does that mean the security team members need admin on all plugin repos, are they supposed to be watching more places for reports etc)
/James
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7edfc904-18b1-4b99-9301-930dee549cd0o%40googlegroups.com.
I would be surprised if we wouldn't regularly get 0-days because people with just a GH account don't bother to do it properly, and just report issues on GH. If that is enabled in repos without someone regularly reviewing incoming issues, or by a maintainer who's unaware of how we handle security issues in the project, reports may linger in public for months or even years.
Having a screen like https://github.com/jenkinsci/configuration-as-code-plugin/issues/new/choose could help here, but that's far from universal right now. Is this something that could be defined via .github? Having a screen similar to this would be the bare minimum for GH issue tracking already today.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8E2ACAC0-AC5D-456E-AF21-E60F92203931%40beckweb.net.
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <m...@beckweb.net> wrote:Having a screen like https://github.com/jenkinsci/configuration-as-code-plugin/issues/new/choose could help here, but that's far from universal right now. Is this something that could be defined via .github? Having a screen similar to this would be the bare minimum for GH issue tracking already today.Yes that is possible, I've just tested it out:(I don't have the security file in my org but it would show up if it was configured)
--You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWgJKcz6nmLU9fR3-tYnrcermc%3DTNK7p9Et4LSA%2BmKtUYQ%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/haFTYlhp7h8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/016c48f3-1c26-4d43-9abb-897560659eab%40www.fastmail.com.
Since now we know we have the GH issues templates... what do you think about creating a central (i.e. pre-defined and shared across all plugins), how about:- creating a unified GH issue template for the whole jenkinsci organisation (i.e. pre-defined template)- push this template via PR to all the plugin repositories (regardless of whether they use Jira or GH)- automatically create new plugin repositories with this template- (?) create a bot that would pull all "security" labelled issues into Jira security project or wherever it may be
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWi%2BTORuHK%2BUS7mVeBSWsgLf%3DzzyK9B_N5K7oxT%2BgFDkAw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieRTUowW6w_m3COParXVKFPkdkU9Qqz8x_neskxDfECfg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieRTUowW6w_m3COParXVKFPkdkU9Qqz8x_neskxDfECfg%40mail.gmail.com.