Plugin pom http/https mass cleanup

[Daniel Beck]

Hi everyone,

a large number of plugins (and possibly other components) define HTTP URLs for dependency resolution and in some cases, distribution repositories. I'd like to clean this up.

There are a few options here:

1. I just directly commit to the repos with this minimal change. AFAICT, Nicolas did something similar in 2013.[1]
2. File a few hundred PRs to change the URL.
3. Start with PRs, but merge myself when maintainers don't. This is basically what Oliver ended up doing when we added Jenkinsfiles to plugin repositories.[2]
4. Do nothing (or perhaps just file bugs)
5. Some other option…?

I do not think it's a reasonable approach to not act here, so option 4 is out. While the risk is low, it's a step in the right direction without any drawbacks I can think of.

My preferred option would be 3: File PRs now, merge when they get no response after an appropriate number of weeks/months. This most respects (active) maintainers' ownership of plugins, while cleaning up both currently unmaintained plugins, as well as (I expect) the vast majority of maintained plugins.

As a side effect, maintainers' (lack of) response to these PRs can be used to identify currently unmaintained plugins. Even during summer holiday season, not merging (nor commenting, nor closing) a trivial PR going from HTTP to HTTPS for perhaps 4-8 weeks or so is a pretty good indicator a plugin is unmaintained. Something similar has been discussed previously[3], but no consensus was reached -- in this case it's just a side effect of some of the approaches.

WDYT?

Daniel


1: E.g. https://github.com/jenkinsci/codecover-plugin/commit/ea652d3fb7b6899e44493e635401dee539ceacd9, lots of long abandoned plugins last got updated in late 2013 because of these commits.
2: https://groups.google.com/d/msg/jenkinsci-dev/6f_wKvfpESk/TKIRm4QvAwAJ
3: https://groups.google.com/d/msg/jenkinsci-dev/Ih0RviQ0G90/NmoVJQ1j6NAJ

[Baptiste Mathus]

Definitely 3 sounds great. 

And yeah, I personally still would like at some point to revive the recurring auto-pr approach from the other thread to cleanup our status wrt. maintainership (and hence encourage new maintainers to step up on abandoned 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/AD30DDD5-3FCC-42CD-B0AB-C88C0BD66435%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <m...@beckweb.net> wrote:
> 3. Start with PRs, but merge myself when maintainers don't. This is basically what Oliver ended up doing when we added Jenkinsfiles to plugin repositories.[2]

+1 for this. An unmentioned benefit over #1 is that CI will catch
fatal mistakes in your tool, and if you are doing some batch POM
transformation with hundreds of cases you are going to have made a
couple of mistakes.

[Mark Waite]

I like #3 as well.

If you're not already using some form of pull request creation script, I recommend the `hub` command from GitHub.  I like submitted a pull request from the same terminal window where I'm performing all my other operations.

--
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/CANfRfr34ErzvKcCVgWCP%2BoqMXTsOND4-OGH0Ddqup3YMSMvE%3DA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks!

Mark Waite

[Jeff Thompson]

Another +1 for approach #3 from me. It's the only approach that makes
any sense as far as I can tell.

Jeff

[Gavin Mogan]

another +1 from me for #3

Especially since you won't have to do a release since its just dev tools, so there's not a lot of risk.

--
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/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com.

[Oleg Nenashev]

+1 for 3

On Thursday, July 11, 2019 at 7:43:57 PM UTC+2, Gavin Mogan wrote:

another +1 from me for #3

Especially since you won't have to do a release since its just dev tools, so there's not a lot of risk.

On Thu, Jul 11, 2019 at 10:26 AM Jeff Thompson <jtho...@cloudbees.com> wrote:

On 7/11/19 8:22 AM, Jesse Glick wrote:
> On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <m...@beckweb.net> wrote:
>> 3. Start with PRs, but merge myself when maintainers don't. This is basically what Oliver ended up doing when we added Jenkinsfiles to plugin repositories.[2]
> +1 for this. An unmentioned benefit over #1 is that CI will catch
> fatal mistakes in your tool, and if you are doing some batch POM
> transformation with hundreds of cases you are going to have made a
> couple of mistakes.

Another +1 for approach #3 from me. It's the only approach that makes
any sense as far as I can tell.

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 jenkin...@googlegroups.com.