Plugin pom http/https mass cleanup

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
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/AD30DDD5-3FCC-42CD-B0AB-C88C0BD66435%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin pom http/https mass cleanup

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

Le jeu. 11 juil. 2019 à 13:51, Daniel Beck <[hidden email]> a écrit :
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

--
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/AD30DDD5-3FCC-42CD-B0AB-C88C0BD66435%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/CANWgJS59jSoEMGJ7qCZvAVfYu4Bq46FC6yfCv%2B2-hFZaeU-bKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin pom http/https mass cleanup

Jesse Glick-4
In reply to this post by Daniel Beck
On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <[hidden email]> 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.

--
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/CANfRfr34ErzvKcCVgWCP%2BoqMXTsOND4-OGH0Ddqup3YMSMvE%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin pom http/https mass cleanup

Mark Waite-2
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.

On Thu, Jul 11, 2019 at 8:23 AM Jesse Glick <[hidden email]> wrote:
On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <[hidden email]> 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.

--
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/CANfRfr34ErzvKcCVgWCP%2BoqMXTsOND4-OGH0Ddqup3YMSMvE%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Thanks!
Mark Waite

--
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/CAO49JtEwz%3DeTCVsQ%3DEu611S_js%3Do3%3D6K%3D6g5URZdpJ0RVJ9kwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin pom http/https mass cleanup

Jeff Thompson
In reply to this post by Jesse Glick-4
On 7/11/19 8:22 AM, Jesse Glick wrote:
> On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin pom http/https mass cleanup

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.

On Thu, Jul 11, 2019 at 10:26 AM Jeff Thompson <[hidden email]> wrote:
On 7/11/19 8:22 AM, Jesse Glick wrote:
> On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

--
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_DusfRwqR50dwDAfsM0KHVZb15cxcuR7OUCDzLcOJTy7s_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin pom http/https mass cleanup

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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="sCxTild4DAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jtho...@...> wrote:
On 7/11/19 8:22 AM, Jesse Glick wrote:
> On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="sCxTild4DAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">m...@...> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="sCxTild4DAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkin...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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/7f864d45-8215-4564-a67f-a3df1e9ca2f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.