Okay, I'd love to hear more ideas, but I really like the explicit configs. (it took me way too long to figure out what RPU was)
So update plugin site to use the data in github.com/jenkins-infra/repository-permissions-updater 1 time mass PR to github.com/jenkins-infra/repository-permissions-updater for each repo. If a repo has github issues enabled, assume it uses that. else If the plugin name has a jira component, assume it uses that. else no issues link issues: github:jenkinsci/configuration-as-code-plugin issues: jira:blueocean-plugin or to daniel's point (might be on the github draft PR), do we want to make it a hash style to support plugins that do both? Its not likely that a plugin will want two, but during a transitory period, it might be worth listing both issues: github: jenkinsci/configurations-as-code jira: blueocean-plugin As a side note, it would be super easy to use that data to also fix SCM, so that things like the blueocean sub modules would have the right scm links since its already part of the metadata - https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-antisamy-markup-formatter.yml#L3 Gavin On Thu, Dec 17, 2020 at 3:07 AM Tim Jacomb <[email protected]> wrote: > Agree tracking it in RPU is probably best > > On Thu, 17 Dec 2020 at 09:27, Daniel Beck <[email protected]> wrote: > >> >> >> > On 17. Dec 2020, at 07:53, 'Gavin Mogan' via Jenkins Developers < >> [email protected]> wrote: >> > >> > 1) Overrides file >> > 2) Issue Managemnet section in pom.xml ( >> > https://maven.apache.org/pom/maven/issue-management.html). I was >> thinking >> > we should use jira:$component-name, or github:repo-name >> > 3) Github if enabled >> > 4) Jira >> > >> > I'm not even sure the data for #2 is exposed to poms and stuff. >> > >> > So looking for feedback on options and what people prefer. >> > >> >> Option 2 won't work due to bad data quality in plugins (tons of obsolete >> URLs -- thanks Jira -- and of course a lot of missing data). Suddenly >> starting to rely on it will not be useful. While this *may* be another >> source of data, it too broken to use as authoritative source. And trying to >> backfill it will probably take forever, see also our wiki migration. >> >> I've been working on something similar to option 1 as the foundation for >> exposing the data via update site metadata (to be able to link there >> directly from Jenkins) for a while now: Extend the metadata we track for >> plugins (via repository-permissions-updater) to include issue tracker >> locations. The benefit is that unused or obsolete trackers that exist for >> historical reasons will be overridable. The drawback is some additional >> effort in making a switch. OTOH, that switch will actually work as opposed >> to a helpful script identifying that Jira/GH issues are non-empty, and >> adding them to the list. >> >> An open question is whether it would remain an "override" for select >> cases, or the sole source of data after an initialization (similar to what >> Jesse did for GitHub URLs). If we want to expose the data in update site >> metadata (which I think would be the correct choice), then it needs to be >> quick to determine, so we need a static source -- which can be either a >> complete configuration, or a list updated periodically by another process. >> The former would be easier. It's also unclear to me how to identify the >> preferred issue tracker for new issues otherwise. >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/6E71437A-E2AF-4F8F-B6D0-71FDE96EA919%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifBhzL%2B2UwBHUpyZxjz1uNWi5bA3k%3DN0OFrtXCBU1KK%2BA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifBhzL%2B2UwBHUpyZxjz1uNWi5bA3k%3DN0OFrtXCBU1KK%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuvV53%2BSjp9Af3YT-SVV7xBM%2BcsKSSoywVA8QFHabBrmg%40mail.gmail.com.
