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

Tim Jacomb
Hi Radek

Jira cloud isn’t an option due to our number of users and a couple of other reasons (there’s a ticket with a summary somewhere in jira)

Linux foundation have offered to host jira though which may at least get us one we don’t have to maintain.

Fully agree with your other points

Maybe we need an evaluation with an updated Jira as some people have said the newer one is better.

I find working with GitHub issues far superior than Jira, and think that we should do more to support GitHub issues, defaulting to enabling it on new plugins, and showing them in the plugin site etc

A document with what people are using each for could be useful? Although the chat discussion hasn’t seemed to have gone anywhere.

One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in Jira

Thanks

Tim 


On Thu, 18 Jun 2020 at 17:00, Radosław Antoniuk <[hidden email]> wrote:

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.

--
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-3Bieun8sG%2BNyOXQmkgcuMVhsJJ6ZhX-9XJoPtuLcmUT6ynA%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 18.06.2020 um 18:00 schrieb Radosław Antoniuk <[hidden email]>:
>
> The superiority of Jira in terms of features is obvious but it shouldn't be an argument.

Why not?

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

Maybe it would make sense to collect all arguments in a document so we can discuss it in the Governance meeting and make a decision on how to proceed.

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


--
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/1E74A58D-44D7-4FC6-9107-0F7238E2B18A%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

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

People added to the develop group for the plugin have admin access to the repo, so enabling GitHub Issues is pretty easy. This is how some repos currently have GitHub Issues enabled now. 

--

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfmwK5RA8YkuB6o7nSWLRsyjt7LgFaWk_M%3DbQ6ViVgyxg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Jesse Glick-4
In reply to this post by Ulli Hafner
On Thu, Jun 18, 2020 at 12:51 PM Ullrich Hafner
<[hidden email]> wrote:
>> 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.

jshell> for (GHRepository r :
GitHub.connect().getOrganization("jenkinsci").listRepositories())
{String n = r.getName(); if (n.endsWith("-plugin") && r.hasIssues())
{System.out.println(n + ": " +
r.getIssues(GHIssueState.ALL).stream().filter(i ->
!i.isPullRequest()).count());}}
rake-plugin: 14
rubymetrics-plugin: 24
accurev-plugin: 1
build-timeout-plugin: 9
cmvc-plugin: 1
configurationslicing-plugin: 1
cobertura-plugin: 60
doclinks-plugin: 2
extended-read-permission-plugin: 2
envfile-plugin: 1
greenballs-plugin: 1
ivy-plugin: 6
maven-repo-cleaner-plugin: 2
maven-dependency-update-trigger-plugin: 7
platformlabeler-plugin: 2
perfpublisher-plugin: 12
scm-sync-configuration-plugin: 40
scp-plugin: 4
sidebar-link-plugin: 1
violations-plugin: 45
depgraph-view-plugin: 2
selenium-plugin: 85
seleniumhtmlreport-plugin: 1
build-name-setter-plugin: 13
plasticscm-plugin: 15
klocwork-plugin: 9
ivytrigger-plugin: 0
urltrigger-plugin: 4
fstrigger-plugin: 1
ansicolor-plugin: 122
rrod-plugin: 1
graven-plugin: 0
dev-mode-plugin: 0
brakeman-plugin: 10
gradle-jpi-plugin: 22
junit-attachments-plugin: 5
silktestsuite-plugin: 1
antexec-plugin: 0
unity3d-plugin: 12
tikal-multijob-plugin: 81
fogbugz-plugin: 2
hipchat-plugin: 98
rbenv-plugin: 32
embeddable-build-status-plugin: 24
yammer-plugin: 5
stackhammer-plugin: 0
regression-report-plugin: 6
leiningen-plugin: 11
cas-plugin: 0
ghprb-plugin: 427
testswarm-plugin: 0
multi-module-tests-publisher-plugin: 6
gitlab-hook-plugin: 29
debian-package-builder-plugin: 25
periodic-reincarnation-plugin: 2
caliper-ci-plugin: 2
recipe-plugin: 0
vertx-plugin: 4
nis-notification-lamp-plugin: 1
audit2db-plugin: 17
coordinator-plugin: 40
slave-proxy-plugin: 0
appdynamics-plugin: 6
cucumber-reports-plugin: 220
stashnotifier-plugin: 156
tag-profiler-plugin: 0
cloudtest-plugin: 1
buildgraph-view-plugin: 9
trac-artifacts-publisher-plugin: 0
zulip-plugin: 16
cloudbees-enterprise-plugins-plugin: 0
wix-plugin: 9
rpmsign-plugin: 7
jqs-monitoring-plugin: 1
sra-deploy-plugin: 1
build-view-column-plugin: 0
rally-plugin: 18
categorized-view-plugin: 12
parallel-test-executor-plugin: 20
rest-service-scheduler-plugin: 0
team-views-plugin: 0
groovy-script-scheduler-plugin: 0
enhanced-old-build-discarder-plugin: 1
mount-point-disk-space-monitor-plugin: 0
mlattach-plugin: 0
newgen-servers-plugin: 0
ec2-cloud-axis-plugin: 1
kerberos-auth-plugin: 0
archived-artifact-url-viewer-plugin: 1
mesos-plugin: 180
junit-realtime-test-reporter-plugin: 1
proxmox-plugin: 3
trial-balloon-plugin: 0
jobtemplates-plugin: 1
selenium-axis-plugin: 2
slack-plugin: 425
lockable-resources-plugin: 98
pom2config-plugin: 0
gatekeeper-plugin: 1
implied-labels-plugin: 1
xlrelease-plugin: 2
docker-plugin: 506
deveo-plugin: 1
flowdock-plugin: 15
google-oauth-plugin: 41
google-storage-plugin: 45
packer-plugin: 18
google-metadata-plugin: 2
poll-mailbox-trigger-plugin: 52
artifact-promotion-plugin: 14
liquibase-runner-plugin: 15
failure-visualizer-plugin: 0
openid4java-plugin: 0
gitlab-plugin: 751
allure-plugin: 171
jabber-server-plugin: 5
azure-slave-plugin: 34
vmanager-plugin: 2
xltestview-plugin: 0
travis-yml-plugin: 2
icon-shim-plugin: 0
page-note-plugin: 0
lucene-search-plugin: 2
saltstack-plugin: 89
aws-beanstalk-publisher-plugin: 33
uithemes-plugin: 2
environment-plugin: 0
matrix-groovy-execution-strategy-plugin: 16
persistent-parameter-plugin: 5
dynatrace-plugin: 7
environment-dashboard-plugin: 50
discobit-autoconfig-plugin: 0
google-source-plugin: 6
font-awesome-icons-plugin: 0
ontrack-plugin: 47
openstack-cloud-plugin: 163
cli-commander-plugin: 1
jackson-databind-plugin: 0
advanced-installer-msi-builder-plugin: 0
inedo-buildmaster-plugin: 0
violation-comments-to-stash-plugin: 54
ssh2easy-plugin: 8
compound-slaves-plugin: 3
seed-plugin: 35
redgate-sql-ci-plugin: 5
sqlplus-script-runner-plugin: 46
azure-publishersettings-credentials-plugin: 0
aws-credentials-plugin: 29
openconnect-plugin: 1
datadog-plugin: 11
groovy-events-listener-plugin: 28
amazon-ecs-plugin: 87
sumologic-publisher-plugin: 3
tinfoil-scan-plugin: 0
git-changelog-plugin: 38
ecutest-plugin: 61
walti-plugin: 0
delphix-plugin: 4
readonly-parameter-plugin: 1
fortify-on-demand-uploader-plugin: 43
sap-hcp-deployer-plugin: 0
salesforce-migration-assistant-plugin: 21
octoperf-plugin: 1
violation-comments-to-github-plugin: 27
bitbucket-branch-source-plugin: 91
cloud-stats-plugin: 10
pipeline-view-plugin: 4
sge-cloud-plugin: 1
cucumber-living-documentation-plugin: 27
prometheus-plugin: 96
imagecomparison-plugin: 0
vncviewer-plugin: 2
vncrecorder-plugin: 1
github-pr-coverage-status-plugin: 44
scm-sqs-plugin: 8
nomad-plugin: 27
ibm-security-appscansource-scanner-plugin: 9
consul-kv-builder-plugin: 8
ec2-fleet-plugin: 111
cisco-spark-plugin: 1
office-365-connector-plugin: 69
oic-auth-plugin: 55
contrast-continuous-application-security-plugin: 2
last-changes-plugin: 69
fabric-beta-publisher-plugin: 25
open-stf-plugin: 7
gogs-webhook-plugin: 26
azure-batch-parallel-plugin: 0
statistics-gatherer-plugin: 12
hashicorp-vault-plugin: 24
aws-sqs-plugin: 21
gerrit-verify-status-reporter-plugin: 3
build-time-blame-plugin: 14
cisco-spark-notifier-plugin: 11
dingtalk-plugin: 36
pipeline-aws-plugin: 124
github-issues-plugin: 9
testrail-plugin: 39
jms-messaging-plugin: 24
github-pr-comment-build-plugin: 17
pipeline-dependency-walker-plugin: 1
aws-cloudwatch-logs-publisher-plugin: 10
device-watcher-plugin: 1
clif-performance-testing-plugin: 0
cloudshare-docker-plugin: 1
violation-comments-to-gitlab-plugin: 22
generic-webhook-trigger-plugin: 148
app-detector-plugin: 0
ibm-ucdeploy-pipeline-plugin: 7
livingdoc-reports-plugin: 0
dotnet-as-script-plugin: 2
ranorex-integration-plugin: 0
pipeline-github-plugin: 59
xlrelease-var-setter-plugin: 1
date-parameter-plugin: 5
cerberus-testing-plugin: 6
aws-codecommit-trigger-plugin: 5
rancher-plugin: 36
coding-webhook-plugin: 11
confluence-pipeline-steps-plugin: 1
outbound-webhook-plugin: 5
azure-cli-plugin: 17
osf-builder-suite-for-sfcc-deploy-plugin: 5
git-bisect-plugin: 7
docker-java-api-plugin: 0
pyenv-pipeline-plugin: 28
azure-container-agents-plugin: 22
azure-acs-plugin: 7
kubernetes-cd-plugin: 80
github-autostatus-plugin: 36
google-cloudbuild-plugin: 8
configuration-as-code-plugin: 608
telegram-notifications-plugin: 31
service-fabric-plugin: 7
benchmark-plugin: 16
azure-ad-plugin: 39
kubernetes-cli-plugin: 11
phoenix-autotest-plugin: 3
working-hours-plugin: 6
service-now-plugin: 8
genexus-plugin: 2
dev-notifier-plugin: 0
docker-swarm-plugin: 47
badge-plugin: 15
arestocats-plugin: 4
google-compute-engine-plugin: 88
code-coverage-api-plugin: 71
hugo-plugin: 2
clever-cloud-plugin: 0
osf-builder-suite-for-sfcc-data-import-plugin: 3
influxdb-query-plugin: 13
aqua-microscanner-plugin: 9
overops-query-plugin: 8
jaxb-plugin: 1
osf-builder-suite-xml-linter-plugin: 0
habitat-plugin: 7
osf-builder-suite-standalone-sonar-linter-plugin: 0
llvm-cov-plugin: 5
cachet-gating-plugin: 4
google-chat-notification-plugin: 19
plasticscm-mergebot-plugin: 0
localization-zh-cn-plugin: 26
aws-sam-plugin: 9
redmine-metrics-report-plugin: 0
in-toto-plugin: 5
zap-pipeline-plugin: 9
multibranch-job-tear-down-plugin: 1
discord-notifier-plugin: 18
audit-log-plugin: 24
log-sanitizer-plugin: 1
bitbucket-push-and-pull-request-plugin: 50
lambda-test-runner-plugin: 4
testproject-plugin: 0
cons3rt-plugin: 0
google-kubernetes-engine-plugin: 37
eiffel-broadcaster-plugin: 3
azure-keyvault-plugin: 20
fortify-plugin: 9
templating-engine-plugin: 47
deepsecurity-smartcheck-plugin: 4
maven-snapshot-check-plugin: 4
config-driven-pipeline-plugin: 2
pipeline-config-history-plugin: 4
git-automerger-plugin: 1
multi-branch-priority-sorter-plugin: 1
remote-file-plugin: 0
sweagle-plugin: 14
pipeline-restful-api-plugin: 1
multibranch-action-triggers-plugin: 1
build-history-manager-plugin: 1
xray-connector-plugin: 6
opencover-plugin: 3
concurrent-step-plugin: 4
pipeline-global-lib-nexus-plugin: 2
osf-builder-suite-for-sfcc-run-job-plugin: 0
s3explorer-plugin: 0
conjur-credentials-plugin: 1
aws-lambda-cloud-plugin: 4
pipeline-as-yaml-plugin: 7
dark-theme-plugin: 42
theme-manager-plugin: 3

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

Re: GitHub issues option in HOSTING

Ulli Hafner
Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-( 

Am 18.06.2020 um 19:36 schrieb Jesse Glick <[hidden email]>:

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

Re: GitHub issues option in HOSTING

Gavin Mogan
> Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-( 

Which is why I want to know what and how we want to support things officially so I can add it to the plugin site.

> The superiority of Jira in terms of features is obvious but it shouldn't be an argument

Just FYI, any time you use the word obvious, its actually not obvious. If its obvious it wouldn't need to be said, but if you say obvious, then something is clear to you, and not to the other people.



Another option is to do what some open source repos do, and have a single repo just for issues


Which would let people use github, could even be github and jira split that way, but still give the power for user to report bugs in a single place, and then triage with labels or something.

I think we have too many components to do that, but it would be another way to handle it.

Gavin


On Thu, Jun 18, 2020 at 10:41 AM Ullrich Hafner <[hidden email]> wrote:
Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-( 

Am 18.06.2020 um 19:36 schrieb Jesse Glick <[hidden email]>:

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

Re: GitHub issues option in HOSTING

Ulli Hafner

> Am 18.06.2020 um 19:48 schrieb 'Gavin Mogan' via Jenkins Developers <[hidden email]>:
>
> > Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-(  
>
> Which is why I want to know what and how we want to support things officially so I can add it to the plugin site.
>

Wouldn’t it then make sense that the people who want officially support GitHub as a second issue tracker would make that an agenda topic for the next governance meeting?
So we can finally come to an official statement? Otherwise this thread will continue indefinitely.

--
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/EFE72EBF-2AD3-4F12-9879-8A3864CD643D%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

slide
Agreed, I think we need to have this as a topic in that meeting. 

I think there are two parts of this topic:
  1. Do we want to allow both Jira and Github issues to coexist in the Jenkins infrastructure? 
    1. This is _somewhat_ moot at this point because we already have a large number of repos that have Github Issues enabled already.
    2. If we want to allow both, do we need to clean up the Jira components of those plugins that are using Github Issues by providing a way to migrate issues from Jira to Github Issues and then removing the component? Also, the opposite, if the plugin developers want to use Jira but Github Issues was enabled on their repository without them wanting it enabled (this could have happened for many reasons), do we need to cleanup the Github Issues and provide a way to migrate issues from Github Issues to Jira?
  2. Do we want to adjust the hosting process to allow selection of the issue tracking (Github Issues or Jira)?
    1. This would mean that the hosting bot would check that field and either:
      1. Create a component in Jira and disable GitHub issues for the repo (this does not preclude the plugin developers team members from re-enabling GitHub Issues after the fact)
      2. No creation of a component in Jira and GitHub issues are NOT disabled

Am I missing anything from this thread?

On Thu, Jun 18, 2020 at 11:12 AM Ullrich Hafner <[hidden email]> wrote:

> Am 18.06.2020 um 19:48 schrieb 'Gavin Mogan' via Jenkins Developers <[hidden email]>:
>
> > Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-( 
>
> Which is why I want to know what and how we want to support things officially so I can add it to the plugin site.
>

Wouldn’t it then make sense that the people who want officially support GitHub as a second issue tracker would make that an agenda topic for the next governance meeting?
So we can finally come to an official statement? Otherwise this thread will continue indefinitely.

--
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/EFE72EBF-2AD3-4F12-9879-8A3864CD643D%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/CAPiUgVek7hYzQAYSUa_sMN9nvpL7hhMKsH7w2ETd1sUrF4zG4Q%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

James Nord-2
> am I missing something in this thread

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7edfc904-18b1-4b99-9301-930dee549cd0o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
On Thu, 18 Jun 2020 at 21:44, James Nord <[hidden email]> wrote:
> am I missing something in this thread

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)

The security team already uses a different project in Jira to everyone else, I don't think we need to change that currently, maintainers will just use whatever the security team decides I would think?

Mentioned this earlier:
> One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in 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/7edfc904-18b1-4b99-9301-930dee549cd0o%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-3Bid81HEKBBJpbk2wNm-s29_OT_rZEOQy0btkGd87nszNxA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
To add to Jesse's numbers here's a summary for the JenkinsCI organisation:

Org report: jenkinsci
Total repositories: 2290
Number with GitHub issues enabled: 355 (15%)
Total issues open: 3338
Total issues closed: 17941
Total issues: 21279


Thanks
Tim

On Thu, 18 Jun 2020 at 21:50, Tim Jacomb <[hidden email]> wrote:
On Thu, 18 Jun 2020 at 21:44, James Nord <[hidden email]> wrote:
> am I missing something in this thread

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)

The security team already uses a different project in Jira to everyone else, I don't think we need to change that currently, maintainers will just use whatever the security team decides I would think?

Mentioned this earlier:
> One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in 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/7edfc904-18b1-4b99-9301-930dee549cd0o%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-3BieYV3wGFQQDmTP_%2BkjrCgxV%3DW0%3DAE4fTJqC50_xEL5f_w%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 18. Jun 2020, at 22:50, Tim Jacomb <[hidden email]> wrote:
>
> The security team already uses a different project in Jira to everyone else, I don't think we need to change that currently, maintainers will just use whatever the security team decides I would think?
>
> Mentioned this earlier:
> > One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in Jira

I already explained earlier that the effectiveness of our work depends on maintainers getting, and then not just ignoring, notifications from Jira. That's made more difficult when they don't use it. Depending on how you count we have between 1 and 4 people contacting maintainers for hundreds of issues a year, anything that makes this more effort or introduces delays will negatively impact our effectiveness.

Additionally, with the vast majority of issues being tracked in Jira, we can fairly easily subscribe to the feed of new issues and move publicly reported vulnerabilities into the private tracker. That doesn't exist on GitHub.

Similarly, users should be able to report security issues without having to jump through hoops. Right now, that's done by accepting reports via email and in the issue tracker most other stuff uses anyway.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8E2ACAC0-AC5D-456E-AF21-E60F92203931%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

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

How about just using "security" label that shall be added by the maintainer and pull all labelled issues automatically via a bot?

 

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

Re: GitHub issues option in HOSTING

Daniel Beck


> On 19. Jun 2020, at 11:47, Radosław Antoniuk <[hidden email]> wrote:
>
>> 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.
>
> How about just using "security" label that shall be added by the maintainer and pull all labelled issues automatically via a bot?

How would that work

> in repos without someone regularly reviewing incoming issues, or by a maintainer who's unaware of how we handle security issues in the project


?

--
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/4E2EB711-EFBA-4065-9BA2-CB69634D55E0%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb
In reply to this post by Daniel Beck
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <[hidden email]> 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)

Thanks
Tim
 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8E2ACAC0-AC5D-456E-AF21-E60F92203931%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/CAH-3BidZqo-KVRKuS08UhbhnXuNH1%3DmGohDpjpucu_EW6NB%3DDw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk
On Fri, Jun 19, 2020 at 12:30 PM Tim Jacomb <[hidden email]> wrote:
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <[hidden email]> 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)
 
Nice, exactly that.
So, security report via a template, that auto-adds "security" label, that can be pulled into (or referenced) a central security project.

--
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/CAPe2pWgJKcz6nmLU9fR3-tYnrcermc%3DTNK7p9Et4LSA%2BmKtUYQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Olblak-2
Hi,

I think this mail discussion is a proof that we won't easily find a consensus any time soon.
I just want to add that we started discussing with Linux foundation  infra team to see if they could maintained a managed version of Jira for us, more information in this email.

So please keep discussing about Jira and/or Github Issues here and things specific to how we maintain issues.jenkins-ci.org on the other thread.

Cheers 

On Fri, Jun 19, 2020, at 12:58 PM, Radosław Antoniuk wrote:
On Fri, Jun 19, 2020 at 12:30 PM Tim Jacomb <[hidden email]> wrote:
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <[hidden email]> 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)
 
Nice, exactly that.
So, security report via a template, that auto-adds "security" label, that can be pulled into (or referenced) a central security project.


--
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/016c48f3-1c26-4d43-9abb-897560659eab%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Radosław Antoniuk

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

?

Radek

On Tue, Jun 23, 2020 at 1:20 PM 'Olblak' via Jenkins Developers <[hidden email]> wrote:
Hi,

I think this mail discussion is a proof that we won't easily find a consensus any time soon.
I just want to add that we started discussing with Linux foundation  infra team to see if they could maintained a managed version of Jira for us, more information in this email.

So please keep discussing about Jira and/or Github Issues here and things specific to how we maintain issues.jenkins-ci.org on the other thread.

Cheers 

On Fri, Jun 19, 2020, at 12:58 PM, Radosław Antoniuk wrote:
On Fri, Jun 19, 2020 at 12:30 PM Tim Jacomb <[hidden email]> wrote:
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <[hidden email]> 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)
 
Nice, exactly that.
So, security report via a template, that auto-adds "security" label, that can be pulled into (or referenced) a central security project.


--
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/016c48f3-1c26-4d43-9abb-897560659eab%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/CAPe2pWi%2BTORuHK%2BUS7mVeBSWsgLf%3DzzyK9B_N5K7oxT%2BgFDkAw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Tim Jacomb


On Wed, 24 Jun 2020 at 16:17, Radosław Antoniuk <[hidden email]> wrote:

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

I agree it would be good to create the GitHub issue templates in the .github repository

Not sure why we would need to create a PR to all plugin repositories as GitHub will automatically use the central one if there isn't one in the repository

There's a PR to archetypes which adds all of our standard files that make plugin maintenance easier:

Thanks
Tim

 

Radek

On Tue, Jun 23, 2020 at 1:20 PM 'Olblak' via Jenkins Developers <[hidden email]> wrote:
Hi,

I think this mail discussion is a proof that we won't easily find a consensus any time soon.
I just want to add that we started discussing with Linux foundation  infra team to see if they could maintained a managed version of Jira for us, more information in this email.

So please keep discussing about Jira and/or Github Issues here and things specific to how we maintain issues.jenkins-ci.org on the other thread.

Cheers 

On Fri, Jun 19, 2020, at 12:58 PM, Radosław Antoniuk wrote:
On Fri, Jun 19, 2020 at 12:30 PM Tim Jacomb <[hidden email]> wrote:
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <[hidden email]> 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)
 
Nice, exactly that.
So, security report via a template, that auto-adds "security" label, that can be pulled into (or referenced) a central security project.


--
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/016c48f3-1c26-4d43-9abb-897560659eab%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/CAPe2pWi%2BTORuHK%2BUS7mVeBSWsgLf%3DzzyK9B_N5K7oxT%2BgFDkAw%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-3BieRTUowW6w_m3COParXVKFPkdkU9Qqz8x_neskxDfECfg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub issues option in HOSTING

Gavin Mogan
I know there's no consensus in this yet, it should get added to governance i think, but I'm fixing github issue ids in release notes


On Wed, Jun 24, 2020 at 8:59 AM Tim Jacomb <[hidden email]> wrote:


On Wed, 24 Jun 2020 at 16:17, Radosław Antoniuk <[hidden email]> wrote:

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

I agree it would be good to create the GitHub issue templates in the .github repository

Not sure why we would need to create a PR to all plugin repositories as GitHub will automatically use the central one if there isn't one in the repository

There's a PR to archetypes which adds all of our standard files that make plugin maintenance easier:

Thanks
Tim

 

Radek

On Tue, Jun 23, 2020 at 1:20 PM 'Olblak' via Jenkins Developers <[hidden email]> wrote:
Hi,

I think this mail discussion is a proof that we won't easily find a consensus any time soon.
I just want to add that we started discussing with Linux foundation  infra team to see if they could maintained a managed version of Jira for us, more information in this email.

So please keep discussing about Jira and/or Github Issues here and things specific to how we maintain issues.jenkins-ci.org on the other thread.

Cheers 

On Fri, Jun 19, 2020, at 12:58 PM, Radosław Antoniuk wrote:
On Fri, Jun 19, 2020 at 12:30 PM Tim Jacomb <[hidden email]> wrote:
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <[hidden email]> 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)
 
Nice, exactly that.
So, security report via a template, that auto-adds "security" label, that can be pulled into (or referenced) a central security project.


--
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/016c48f3-1c26-4d43-9abb-897560659eab%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/CAPe2pWi%2BTORuHK%2BUS7mVeBSWsgLf%3DzzyK9B_N5K7oxT%2BgFDkAw%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-3BieRTUowW6w_m3COParXVKFPkdkU9Qqz8x_neskxDfECfg%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_DuuJ6-DY7BmnqkOxs%2BAY%2BQ7RbqxwbsCxp-xcUqH19q4KPQ%40mail.gmail.com.
12345