[PROPOSAL] Semi-automated detection of unmaintained plugins

[Stephen Connolly]

In pseudocode:

FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)

  CREATE PULL REQUEST update base jenkins version to LTS-1

END

WAIT 1 month

I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin

I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.

We can lather rinse and repeat the above process every couple of months.

With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.

I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.

Thoughts?

-Stephen

[Vincent Latombe]

You might get compilation errors because of plugin extracted from core when applying such a process.

Some plugins are really simple and may not need evolution because they just work as is. How would the attic be represented ? Should it be exposed to users in update center?

Vincent

--
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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

On 9 June 2015 at 09:37, Vincent Latombe <vincent...@gmail.com> wrote:

You might get compilation errors because of plugin extracted from core when applying such a process.

And if somebody steps up and rejects the pull request because of such issues... w00t we have a maintainer for that project.

If nobody (other than the bots) comment or otherwise look at the project for more than 1 month... then to the attic

 

Some plugins are really simple and may not need evolution because they just work as is. How would the attic be represented ?

I would suggest that we could either move them to an "attic" grouping in the update center or remove them from the update center

 

Should it be exposed to users in update center?

That is a question for the community... first step is to identify how many of the 1000+ plugins actually have a maintainer that is willing to look at pull requests

 

Vincent

2015-06-09 10:24 GMT+02:00 Stephen Connolly <stephen.al...@gmail.com>:

In pseudocode:

FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)

  CREATE PULL REQUEST update base jenkins version to LTS-1

END

WAIT 1 month

I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin

I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.

We can lather rinse and repeat the above process every couple of months.

With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.

I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.

Thoughts?

-Stephen

--
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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-zGCis6qGaKXzS5X6t-_2FZH%3D1LSjoKDK40tQHJEYUJdHfLQ%40mail.gmail.com.

[Stephen Connolly]

On 9 June 2015 at 09:37, Vincent Latombe <vincent...@gmail.com> wrote:

You might get compilation errors because of plugin extracted from core when applying such a process.

Some plugins are really simple and may not need evolution because they just work as is.

But they can all benefit from a more recent core (to fix issues with jelly pages, etc)

 

How would the attic be represented ? Should it be exposed to users in update center?

Vincent

2015-06-09 10:24 GMT+02:00 Stephen Connolly <stephen.al...@gmail.com>:

In pseudocode:

FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)

  CREATE PULL REQUEST update base jenkins version to LTS-1

END

WAIT 1 month

I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin

I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.

We can lather rinse and repeat the above process every couple of months.

With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.

I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.

Thoughts?

-Stephen

--
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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-zGCis6qGaKXzS5X6t-_2FZH%3D1LSjoKDK40tQHJEYUJdHfLQ%40mail.gmail.com.

[domi]

+1 for Stephens suggestion.

in the long run this would hopefully even allow to finally remove deprecated stuff…

/Domi

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwyQvoDnYYQeSjqj7gnrmdtqfYQy3CsJLDp5DWgS0ZiKA%40mail.gmail.com.

[Daniel Beck]

We should definitely find out which plugins are unmaintained, and try to find maintainers for them, so +1 on that.

I'm not sure about some of the details of your proposal (like the 1 month period between opening the PR and declaring the plugin unmaintained, or the aggressive updating of Jenkins parent versions), but overall it looks sensible.

What exactly is the 'attic' status? Does it change anything for the plugin, or users of the plugin, other than showing up on the list of plugins in the attic?

[Daniel Beck]

On 09.06.2015, at 10:24, Stephen Connolly <stephen.al...@gmail.com> wrote:

> FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)
> CREATE PULL REQUEST update base jenkins version to LTS-1

FWIW this only really works if we enforce (or at least expect) hosting in and releases from jenkinsci org for plugins in the UC.

We also need to think about what to do with the plugins still hosted in Subversion. I know at least three of those are still actively maintained. Maybe deprecate SVN and shut it down in half a year?

[Stephen Connolly]

On 9 June 2015 at 11:11, Daniel Beck <m...@beckweb.net> wrote:

We should definitely find out which plugins are unmaintained, and try to find maintainers for them, so +1 on that.

I'm not sure about some of the details of your proposal (like the 1 month period between opening the PR and declaring the plugin unmaintained, or the

 

aggressive updating of Jenkins parent versions

What is aggressive. We can even have the PR's message say "Hey we are just checking if anyone is maintaining this plugin, if you are we would appreciate if you can update the parent to 1.596.2, but if you don't want to - for your own good reasons - just state those reasons and close this PR without merging"

All I want to see is that the PR gets a review by a maintainer... I don't care what the review result is ;-)

 

), but overall it looks sensible.

What exactly is the 'attic' status? Does it change anything for the plugin, or users of the plugin, other than showing up on the list of plugins in the attic?

On 09.06.2015, at 10:24, Stephen Connolly <stephen.al...@gmail.com> wrote:

> In pseudocode:
>
> FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)
>   CREATE PULL REQUEST update base jenkins version to LTS-1
> END
> WAIT 1 month
>
> I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin
>
> I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.
>
> We can lather rinse and repeat the above process every couple of months.
>
> With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.
>
> I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.
>
> Thoughts?
>
> -Stephen
>

> --
> 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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C21AFC36-CCD7-4619-9B0D-62B66D674AFB%40beckweb.net.

[Stephen Connolly]

On 9 June 2015 at 11:11, Daniel Beck <m...@beckweb.net> wrote:

We should definitely find out which plugins are unmaintained, and try to find maintainers for them, so +1 on that.

I'm not sure about some of the details of your proposal (like the 1 month period between opening the PR and declaring the plugin unmaintained, or the aggressive updating of Jenkins parent versions), but overall it looks sensible.

What exactly is the 'attic' status? Does it change anything for the plugin, or users of the plugin, other than showing up on the list of plugins in the attic?

Maybe we just inject the attic status into the description text e.g.

Note I am not picking on the CAS protocol version 1 plugin, just hacking up a screenshot where I altered the "excerpt" to 

<strong class="warning">This plugin has no active maintainers and has been put into the plugin <a href="blah">attic</a></strong><br><br>This plugin lets Hudson authenticate users via your organization's Central Authentication Service (<a href="http://www.jasig.org/cas">CAS</a>), for single-sign-on.

Which works as the excerpt is treated as HTML
​ 

On 09.06.2015, at 10:24, Stephen Connolly <stephen.al...@gmail.com> wrote:

> In pseudocode:
>
> FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)
>   CREATE PULL REQUEST update base jenkins version to LTS-1
> END
> WAIT 1 month
>
> I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin
>
> I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.
>
> We can lather rinse and repeat the above process every couple of months.
>
> With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.
>
> I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.
>
> Thoughts?
>
> -Stephen
>

> --
> 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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C21AFC36-CCD7-4619-9B0D-62B66D674AFB%40beckweb.net.

[Kanstantsin Shautsou]

On Tuesday, June 9, 2015 at 11:24:38 AM UTC+3, Stephen Connolly wrote:

In pseudocode:

FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)

  CREATE PULL REQUEST update base jenkins version to LTS-1

END

WAIT 1 month

This wouldn't work for many people, it has no reasons for doing this. I will expect that people will start forking UCs to not deal with such craziness/infra.  

I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin

Wrong assumption. 

Kohsuke wants to have infra with low barrier for joining/working, such proposal adds useless load to people that slowly works on their plugin. As maintainer i'm opening sometimes WIP PRs to plugin just to indicate that some work is going. Or there is some work that requires resolution and still blocked by some factors.

I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.

Cool, you can start with enhancing documentation, updating confluence, doing consulting and helping 1k plugins to be better. You can start doing this with top50 plugins like git that can't even handle exceptions throwing/chaining right.

We can lather rinse and repeat the above process every couple of months.

With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.

Again, it kills initial goal of jenkinsci hosting.

 

I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.

Thoughts?

-Stephen

Could you show any project that has such rules?

[Stephen Connolly]

The Apache Software Foundation can and does put any project that has failed to respond to pings for 3 successive monthly board reports into the attic (after a process to try and reboot the project before hand)

--
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/0cb24e67-48b2-47ee-96d5-ec02cab338a4%40googlegroups.com.

[jieryn]

https://wiki.jenkins-ci.org/display/JENKINS/Plugin+Report+Card

--

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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.com.

[Kanstantsin Shautsou]

With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.

Btw no need in cutting/releasing plugins from UC list. It should be enough to create good UC in jenkins that will provide ratings/sorting by download/last commit or any other values. Then you can filter list of plugins down to your personal accepted level.

[Bruno P. Kinoshita]

I think someone mentioned/suggested that some time ago https://github.com/jenkins-infra/infra-rating

I tried to extend it to something similar to how you use&rate plug-ins in Wordpress https://github.com/kinow/infra-rating

It has been in my TODO list to re-implement that, so that I can use and receive feedback on plug-ins in custom UC's (using that UpdateSites plugin).

Just my 0.02 cents

Bruno

---

From: Kanstantsin Shautsou <kanstan...@gmail.com>
To: jenkin...@googlegroups.com
Sent: Tuesday, June 9, 2015 11:28 PM
Subject: Re: [PROPOSAL] Semi-automated detection of unmaintained plugins

With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.

Btw no need in cutting/releasing plugins from UC list. It should be enough to create good UC in jenkins that will provide ratings/sorting by download/last commit or any other values. Then you can filter list of plugins down to your personal accepted level.

--
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/90c47f40-1121-4868-a82b-e4f9124a57a3%40googlegroups.com.

[Baptiste Mathus]

+1 Good idea. At first before opening your full message, I thought 3 months for last commit would be far too limiting. But the PR idea is very cool: simple and to the point. The maintainer can just answer something standard or something at all to prevent his plugin going to the attic state.

There could even be something like the process posting a second warning as a comment after a grace period like "It's been one month, please add a comment before blablabla so that that plugins isn't tagged as attic".

Btw, there should also be a documented way to move a plugin out of the attic (either because you missed the PR, or because a plugin got new maintainers).

-- Baptiste

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CC6191C9-EC2C-4E39-B425-150638A026D7%40fortysix.ch.

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

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Kanstantsin Shautsou]

> On Jun 9, 2015, at 15:47, Baptiste Mathus <bma...@batmat.net> wrote:
>
> +1 Good idea. At first before opening your full message, I thought 3 months for last commit would be far too limiting. But the PR idea is very cool: simple and to the point. The maintainer can just answer something standard or something at all to prevent his plugin going to the attic state.
>
> There could even be something like the process posting a second warning as a comment after a grace period like "It's been one month, please add a comment before blablabla so that that plugins isn't tagged as attic".
>
> Btw, there should also be a documented way to move a plugin out of the attic (either because you missed the PR, or because a plugin got new maintainers).

Why end-user in update center should care about when last commit was done? If plugin works and solves user issues - nobody cares and this label will just confuse. Some plugins are jut libraries (like github-api plugin) and they can be stable for long time, such PRs will look like WTF.

[Baptiste Mathus]

End users are (typically) Jenkins admins. 

I am one of those people. 

I totally care about if a plugin is actually abandonned when I install it. 

I always look at the number of installations, and I would definitely consider that information and find it absolutely valuable.

Sure, plugins may indeed not receive much modifications (for one, our BTB plugin is a good example) because it's stable and has very few features. 

But that it's not abandonned is an information indeed valuable to end user. 

-- Baptiste

[Stephen Connolly]

On 9 June 2015 at 13:47, Baptiste Mathus <bma...@batmat.net> wrote:

+1 Good idea. At first before opening your full message, I thought 3 months for last commit would be far too limiting. But the PR idea is very cool: simple and to the point. The maintainer can just answer something standard or something at all to prevent his plugin going to the attic state.

There could even be something like the process posting a second warning as a comment after a grace period like "It's been one month, please add a comment before blablabla so that that plugins isn't tagged as attic".

Yep... could work also... in fact the bot could be running all the time so that as soon as a github repo drops off the 3 month activity window the pull request gets created... but that might only work for maven based repos

 

Btw, there should also be a documented way to move a plugin out of the attic (either because you missed the PR, or because a plugin got new maintainers).

I think the simplest thing is that somebody steps up and says "I would like to be the maintainer"

What the process does is it provides a way to say "this plugin has no maintainer" and thus there is nobody that you are "pushing out" or needing to ask.

Right now if the maintainer has walked away you don't know and you can waste a lot of time trying to contact them at potentially a dead email address or one where the spam filters are hyper-aggressive

By flushing out maintainers who have gone awol we leave the plugin available for new maintainers to adopt without fear of causing offense

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4wVgUPV-gBLtbmGqkGg6kCCQp_xoavuHoZ8oQT9VNcZA%40mail.gmail.com.

[Stephen Connolly]

So let's take the github api plugin as an example so.

The PR gets created. The current maintainer responds to the PR with "Don't want to update the parent because XYZ" and that's it for another 3 months.

We get two benefits from this:

* We find out the plugins that have a maintainer who is pinging the project at least once per month

* We gently nudge all the plugins to use a newer baseline (which will allow for tidy-up of the code)

What's not to like?

-Stephen

 

-- Baptiste

--
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/CANWgJS5v_KZmSvEtO0%3DOYbDSLb%2BWFiwhYTZ%3DpDTFjvExNbVt%3Dg%40mail.gmail.com.

[Christopher Orr]

On 09/06/15 12:57, Stephen Connolly wrote:
> On 9 June 2015 at 11:11, Daniel Beck <m...@beckweb.net

> <mailto:m...@beckweb.net>> wrote:
>
> We should definitely find out which plugins are unmaintained, and
> try to find maintainers for them, so +1 on that.

Yes, it would be great to know which plugins are unmaintained, for when
another developer comes along and wants to make changes. Then we can
avoid the usual "wait X weeks for a response, and try and get hold of
the last-known maintainer etc..."

Though if a plugin just works, I'm not sure we need to *actively* ensure
that each plugin always has a maintainer. I'm not sure how that would
work anyway — presumably the majority of those plugins would just remain
in the "looking for a maintainer" state. But yeah, that's good enough
if we just want to flag that a plugin is definitely unmaintained.

> I'm not sure about some of the details of your proposal (like the 1
> month period between opening the PR and declaring the plugin
> unmaintained, or the aggressive updating of Jenkins parent
> versions), but overall it looks sensible.

Out of interest, what is the benefit of updating the parent version like
this? I don't recall hearing any benefits about this in the past --
what are the "issues with jelly pages" that get improved, for example?

In addition to the parent version update pull request, does this plan
also require *releasing* a new version of the plugin? If so, that seems
like a burden on Jenkins users if every three months they have to update
virtually every single Jenkins plugin they have installed?

> What exactly is the 'attic' status? Does it change anything for the
> plugin, or users of the plugin, other than showing up on the list of
> plugins in the attic?
>
>
> Maybe we just inject the attic status into the description text e.g.
> [image]
>
> Note I am not picking on the CAS protocol version 1 plugin, just hacking
> up a screenshot where I altered the "excerpt"

As a user, I'm not sure whether having this info on a quarter of all
plugins in the Update Centre would be useful. If the plugin works, I
won't really care whether it hasn't been updated in X months?

If anything, some sort of "hey, this is unmaintained" signal in the
"Maintainers" area of the wiki infobox might be more useful?

> On 09.06.2015, at 10:24, Stephen Connolly
> <stephen.al...@gmail.com

[Kanstantsin Shautsou]

On Jun 9, 2015, at 16:14, Stephen Connolly <stephen.al...@gmail.com> wrote:

On 9 June 2015 at 14:05, Baptiste Mathus <bma...@batmat.net> wrote:

2015-06-09 14:53 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:

> On Jun 9, 2015, at 15:47, Baptiste Mathus <bma...@batmat.net> wrote:
>
> +1 Good idea. At first before opening your full message, I thought 3 months for last commit would be far too limiting. But the PR idea is very cool: simple and to the point. The maintainer can just answer something standard or something at all to prevent his plugin going to the attic state.
>
> There could even be something like the process posting a second warning as a comment after a grace period like "It's been one month, please add a comment before blablabla so that that plugins isn't tagged as attic".
>
> Btw, there should also be a documented way to move a plugin out of the attic (either because you missed the PR, or because a plugin got new maintainers).

Why end-user in update center should care about when last commit was done? If plugin works and solves user issues - nobody cares and this label will just confuse. Some plugins are jut libraries (like github-api plugin) and they can be stable for long time, such PRs will look like WTF. 

End users are (typically) Jenkins admins. 

I am one of those people. 

I totally care about if a plugin is actually abandonned when I install it. 

I always look at the number of installations, and I would definitely consider that information and find it absolutely valuable.

Sure, plugins may indeed not receive much modifications (for one, our BTB plugin is a good example) because it's stable and has very few features. 

But that it's not abandonned is an information indeed valuable to end user. 

So let's take the github api plugin as an example so.

The PR gets created. The current maintainer responds to the PR with "Don't want to update the parent because XYZ" and that's it for another 3 months.

We get two benefits from this:

* We find out the plugins that have a maintainer who is pinging the project at least once per month

* We gently nudge all the plugins to use a newer baseline (which will allow for tidy-up of the code)

What's not to like?

Jenkins FOSS has not much resources (in comparison to CloudBees) for wasting time for such activities. github-api plugin released with kk agreement by me or oleg. But no one from us ha time for answering for spam PRs. I know projects where ISSUES can be created automatically, but not RPs. I also expect that your algorithm will spam die with master-slave changes. 

New baseline why? Just because you want? Why people with older jenkins versions must loose updates (note 2-3 LTS lines may have some update blockers for users)?

-Stephen

 

-- Baptiste

--
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/CANWgJS5v_KZmSvEtO0%3DOYbDSLb%2BWFiwhYTZ%3DpDTFjvExNbVt%3Dg%40mail.gmail.com.

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

--

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/Ih0RviQ0G90/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/CA%2BnPnMxpf0p71gLzUWRaT6QdBOu2Pv%2BYFpv5J6hM9uUJO9Oozw%40mail.gmail.com.

[Kanstantsin Shautsou]

On Jun 9, 2015, at 16:15, Christopher Orr <ch...@orr.me.uk> wrote:

On 09/06/15 12:57, Stephen Connolly wrote:

On 9 June 2015 at 11:11, Daniel Beck <m...@beckweb.net
<mailto:m...@beckweb.net>> wrote:

   We should definitely find out which plugins are unmaintained, and
   try to find maintainers for them, so +1 on that.

Yes, it would be great to know which plugins are unmaintained, for when another developer comes along and wants to make changes.  Then we can avoid the usual "wait X weeks for a response, and try and get hold of the last-known maintainer etc..."

Though if a plugin just works, I'm not sure we need to *actively* ensure that each plugin always has a maintainer.  I'm not sure how that would work anyway — presumably the majority of those plugins would just remain in the "looking for a maintainer" state.  But yeah, that's good enough if we just want to flag that a plugin is definitely unmaintained.

I agree that after somebody come to plugin and resolved that plugin not maintained (after trying to contact maintainer, writing to maillist) such info should be saved. 

As first question i will be interesting to hear what to do with <developers> section in pom.xml. In gentoo for example email of contact developer in ebuild changes to maintainer-wanted@ maintainer-needed@ and then bugs for such plugins addressed to mass list where anyone from approved developers/maintainers can handle bugs. Also if maintainer/developer is known to be absent for a long time it gets “retired” status https://wiki.gentoo.org/wiki/Project:Infrastructure/Retire_Process and access to infra blocked (security reasons, rules changing reasons). If he decide back he passes quiz (based on available documentation) again - because many things may change and project must ensure that this person knows what is happening. 

--
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/Ih0RviQ0G90/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/5576E70F.60509%40orr.me.uk.

[Kanstantsin Shautsou]

On Jun 9, 2015, at 16:05, Baptiste Mathus <bma...@batmat.net> wrote:

2015-06-09 14:53 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:

> On Jun 9, 2015, at 15:47, Baptiste Mathus <bma...@batmat.net> wrote:
>
> +1 Good idea. At first before opening your full message, I thought 3 months for last commit would be far too limiting. But the PR idea is very cool: simple and to the point. The maintainer can just answer something standard or something at all to prevent his plugin going to the attic state.
>
> There could even be something like the process posting a second warning as a comment after a grace period like "It's been one month, please add a comment before blablabla so that that plugins isn't tagged as attic".
>
> Btw, there should also be a documented way to move a plugin out of the attic (either because you missed the PR, or because a plugin got new maintainers).

Why end-user in update center should care about when last commit was done? If plugin works and solves user issues - nobody cares and this label will just confuse. Some plugins are jut libraries (like github-api plugin) and they can be stable for long time, such PRs will look like WTF.

End users are (typically) Jenkins admins. 

Wrong, i know more examples where jenkins is used by developers (just because not every projects wants stuff jenkins admins because of using jenkins). And the main problem why jenkins require “admins” (imho of course) - it complexity, bugs, problems, bad UI. (In comparison to TeamCity for example).

I am one of those people. 

I totally care about if a plugin is actually abandonned when I install it. 

I always look at the number of installations, and I would definitely consider that information and find it absolutely valuable.

Create filters in UC. And filter as you want “> 1k installations, not abandoned, not assigned, 5 stars rating, etc”.

[Kanstantsin Shautsou]

The Apache Software Foundation can and does put any project that has failed to respond to pings for 3 successive monthly board reports into the attic (after a process to try and reboot the project before hand)

Can i come to Apache SF and just commit to maven what i want? Can i just host and use coding style that i want under Apache SF?

[Stephen Connolly]

On 9 June 2015 at 15:08, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

The Apache Software Foundation can and does put any project that has failed to respond to pings for 3 successive monthly board reports into the attic (after a process to try and reboot the project before hand)

Can i come to Apache SF and just commit to maven what i want?

Different projects have different rules for their commit bit.

If you are a committer on *any project* in the ASF then you can commit to:

* the commons project.

* the maven sandbox (an area for contributions outside of the maven core team)

* etc

As a member of the ASF I can commit to any project at all (modulo adding myself to the committers group, but members can do that... typically considered rude... it's within the rules however)

But you were asking for an example where a foundation retired inactive projects into an attic... not universal commit bit. If you want my opinion, universal commit bit would be a good thing for the ASF and experiments like the one the commons project is doing should show that and encourage other projects at the ASF to follow.

 

Can i just host and use coding style that i want under Apache SF?

The ASF is a different beast. The ASF does not host personal projects, you must show a community before a project can be hosted at the ASF... and as such the community of that project would get to decide their coding style. 

--
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/94332f17-9f95-4374-a179-db1070b60e7e%40googlegroups.com.

[Stephen Connolly]

On 9 June 2015 at 14:48, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

On Jun 9, 2015, at 16:14, Stephen Connolly <stephen.al...@gmail.com> wrote:

On 9 June 2015 at 14:05, Baptiste Mathus <bma...@batmat.net> wrote:

2015-06-09 14:53 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:

> On Jun 9, 2015, at 15:47, Baptiste Mathus <bma...@batmat.net> wrote:
>
> +1 Good idea. At first before opening your full message, I thought 3 months for last commit would be far too limiting. But the PR idea is very cool: simple and to the point. The maintainer can just answer something standard or something at all to prevent his plugin going to the attic state.
>
> There could even be something like the process posting a second warning as a comment after a grace period like "It's been one month, please add a comment before blablabla so that that plugins isn't tagged as attic".
>
> Btw, there should also be a documented way to move a plugin out of the attic (either because you missed the PR, or because a plugin got new maintainers).

Why end-user in update center should care about when last commit was done? If plugin works and solves user issues - nobody cares and this label will just confuse. Some plugins are jut libraries (like github-api plugin) and they can be stable for long time, such PRs will look like WTF. 

End users are (typically) Jenkins admins. 

I am one of those people. 

I totally care about if a plugin is actually abandonned when I install it. 

I always look at the number of installations, and I would definitely consider that information and find it absolutely valuable.

Sure, plugins may indeed not receive much modifications (for one, our BTB plugin is a good example) because it's stable and has very few features. 

But that it's not abandonned is an information indeed valuable to end user. 

So let's take the github api plugin as an example so.

The PR gets created. The current maintainer responds to the PR with "Don't want to update the parent because XYZ" and that's it for another 3 months.

We get two benefits from this:

* We find out the plugins that have a maintainer who is pinging the project at least once per month

* We gently nudge all the plugins to use a newer baseline (which will allow for tidy-up of the code)

What's not to like?

Jenkins FOSS has not much resources (in comparison to CloudBees) for wasting time for such activities. github-api plugin released with kk agreement by me or oleg. But no one from us ha time for answering for spam PRs.

Seriously, you do not have time to just reply "ACK" to the PR email?

 

I know projects where ISSUES can be created automatically, but not RPs. I also expect that your algorithm will spam die with master-slave changes. 

New baseline why? Just because you want? Why people with older jenkins versions must loose updates (note 2-3 LTS lines may have some update blockers for users)?

-Stephen

 

-- Baptiste

--
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/CANWgJS5v_KZmSvEtO0%3DOYbDSLb%2BWFiwhYTZ%3DpDTFjvExNbVt%3Dg%40mail.gmail.com.

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

--
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/Ih0RviQ0G90/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/CA%2BnPnMxpf0p71gLzUWRaT6QdBOu2Pv%2BYFpv5J6hM9uUJO9Oozw%40mail.gmail.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2A71F431-6C3A-4110-9CC7-0F87EE56E119%40gmail.com.

[Kanstantsin Shautsou]

On Tuesday, June 9, 2015 at 5:25:33 PM UTC+3, Stephen Connolly wrote:

On 9 June 2015 at 15:08, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

The Apache Software Foundation can and does put any project that has failed to respond to pings for 3 successive monthly board reports into the attic (after a process to try and reboot the project before hand)

Can i come to Apache SF and just commit to maven what i want?

Different projects have different rules for their commit bit.

If you are a committer on *any project* in the ASF then you can commit to:

* the commons project.

* the maven sandbox (an area for contributions outside of the maven core team)

* etc

As a member of the ASF I can commit to any project at all (modulo adding myself to the committers group, but members can do that... typically considered rude... it's within the rules however)

Have you accepted any agreement with some rules before joining ASF and getting permissions? 

[Stephen Connolly]

On 9 June 2015 at 16:38, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

On Tuesday, June 9, 2015 at 5:25:33 PM UTC+3, Stephen Connolly wrote:

On 9 June 2015 at 15:08, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

The Apache Software Foundation can and does put any project that has failed to respond to pings for 3 successive monthly board reports into the attic (after a process to try and reboot the project before hand)

Can i come to Apache SF and just commit to maven what i want?

Different projects have different rules for their commit bit.

If you are a committer on *any project* in the ASF then you can commit to:

* the commons project.

* the maven sandbox (an area for contributions outside of the maven core team)

* etc

As a member of the ASF I can commit to any project at all (modulo adding myself to the committers group, but members can do that... typically considered rude... it's within the rules however)

Have you accepted any agreement with some rules before joining ASF and getting permissions? 

To get commit access you sign the CLA

There is nothing else to do. The CLA just covers the assignment of "copyright" (although technically committers retain the copyright of their commits and they are just granting a license to the AFS)

The CLA does not have a code of conduct nor rules

To get membership access you are invited by the members based on your behaviour. Nothing to sign or agree to with regards to codes of conduct or rules of behaviour... there is some stuff to do with the fact that the ASF is a corporation backed by members... but nothing that says I cannot go and add myself to all the projects at the ASF

 

But you were asking for an example where a foundation retired inactive projects into an attic... not universal commit bit. If you want my opinion, universal commit bit would be a good thing for the ASF and experiments like the one the commons project is doing should show that and encourage other projects at the ASF to follow.

 

Can i just host and use coding style that i want under Apache SF?

The ASF is a different beast. The ASF does not host personal projects, you must show a community before a project can be hosted at the ASF... and as such the community of that project would get to decide their coding style. 

--
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/94332f17-9f95-4374-a179-db1070b60e7e%40googlegroups.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/10825bc1-c703-4c19-8a17-46f37636b24f%40googlegroups.com.

[Daniel Beck]

On 09.06.2015, at 17:38, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

> Have you accepted any agreement with some rules before joining ASF and getting permissions?

One of the project's values is to have a low barrier to entry. Don't confuse this with the absence of rules, or that they will stay the same forever. Rules and processes need to adapt to a changing environment.

Stephen identified a problem here, and suggested a solution that is very low effort for everyone involved. Or do you consider responding to a pull request only if your plugin hasn't had any activity in months to be significant effort?

[Baptiste Mathus]

IMO, it can't be so. Kanstantsin actually spent more energy in this thread than the required effort to answer dozens of those Stephen's "polling PRs".

[oliver gondža]

I am afraid every 3 months is just too often. Consider Tmp Cleaner[1], a
working plugin with no pending pull requests that would receive ~14 such
pings from the last release in 2011.

If we would like to detect plugins that can be removed as useless or fixed
not to rely on core API we would like to deprecate, we should target
plugins not updated in years - not months. Sending such PR once a year
sounds better to me.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Tmp+Cleaner+Plugin
--
oliver

[Martin Weber]

Am Dienstag, 9. Juni 2015, 23:56:22 schrieb oliver gondža:
> I am afraid every 3 months is just too often. Consider Tmp Cleaner[1], a
> working plugin with no pending pull requests that would receive ~14 such
> pings from the last release in 2011.
>
> If we would like to detect plugins that can be removed as useless or fixed
> not to rely on core API we would like to deprecate, we should target
> plugins not updated in years - not months. Sending such PR once a year
> sounds better to me.

In case of cmakebuilder, the original maintainer seems to have retired
silently. Couldn´t that be a minimal criterion to mark plugins as
unmaintained?

Martin

[1] https://wiki.jenkins-ci.org/display/JENKINS/cmakebuilder+Plugin

--
Cd wrttn wtht vwls s mch trsr.

[Daniel Beck]

On 10.06.2015, at 00:27, Martin Weber <fifteen...@gmail.com> wrote:

> In case of cmakebuilder, the original maintainer seems to have retired
> silently. Couldn´t that be a minimal criterion to mark plugins as
> unmaintained?

How would we learn that they retired? We could establish some way for maintainers to tell us that they "step down", but my guess is that this won't work for the majority of plugins. Maintainers that gradually lose interest, won't bother to declare they are leaving.

[Martin Weber]

Sorry, (newbie idea):
My assumption was that the maintainer info on the projects wiki page gets
auto-generated from the project´s pom developer section.

[Richard Bywater]

Personally I'd be if favour of presenting a "last modified" date in the update centre to give people an indication of the last update and then do a 6 monthly/yearly ping as Oliver suggests.

Richard

--
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/op.xzzgj8rtsbfict%40localhost.localdomain.

[Bruno P. Kinoshita]

+1 for the attic idea. Not sure which would be the best process for moving them to the attic though. It works quite well in ASF, including in Apache Commons (where I'm trying to push Apache Commons Jelly forward so it doesn't go to the Commons attic, and we can someday maybe drop our patched version :).

If users can view some kind of rating, download number, attic status and maybe user comments somewhere under Manage Plug-ins, I think that would make it easier to choose which plug-ins are reliable to be used in production.

Bruno

---

From: Stephen Connolly <stephen.al...@gmail.com>
To: "jenkin...@googlegroups.com" <jenkin...@googlegroups.com>
Sent: Tuesday, June 9, 2015 10:57 PM

Subject: Re: [PROPOSAL] Semi-automated detection of unmaintained plugins

On 9 June 2015 at 11:11, Daniel Beck <m...@beckweb.net> wrote:

We should definitely find out which plugins are unmaintained, and try to find maintainers for them, so +1 on that.

I'm not sure about some of the details of your proposal (like the 1 month period between opening the PR and declaring the plugin unmaintained, or the aggressive updating of Jenkins parent versions), but overall it looks sensible.

What exactly is the 'attic' status? Does it change anything for the plugin, or users of the plugin, other than showing up on the list of plugins in the attic?

Maybe we just inject the attic status into the description text e.g.

Note I am not picking on the CAS protocol version 1 plugin, just hacking up a screenshot where I altered the "excerpt" to 

<strong class="warning">This plugin has no active maintainers and has been put into the plugin <a href="blah">attic</a></strong><br><br>This plugin lets Hudson authenticate users via your organization's Central Authentication Service (<a href="http://www.jasig.org/cas">CAS</a>), for single-sign-on.

Which works as the excerpt is treated as HTML
​ 

On 09.06.2015, at 10:24, Stephen Connolly <stephen.al...@gmail.com> wrote:

> In pseudocode:
>
> FOR repo IN (SELECT repo FROM github WHERE last_commit < now - 3 months)
>   CREATE PULL REQUEST update base jenkins version to LTS-1
> END
> WAIT 1 month
>
> I suggest that any repo that has not commented / merged / rejected those pull requests is a dead plugin
>
> I suggest that we would subsequently start a campaign to either find maintainers or move those into an attic/deprecated status.
>
> We can lather rinse and repeat the above process every couple of months.
>
> With 1000+ plugins we need to start culling/tidying up the unmaintained cruft.
>
> I think an "attic" status is a better name for such a cull. It's different from deprecated, it's more saying nobody was playing with these toys, so we'll put them in the attic until somebody decides to play with them again.
>
> Thoughts?
>
> -Stephen
>

> --
> 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/CA%2BnPnMwPAD4zLsabwaWTP5t5h1e79KoFu-1XMpkizbn7o66QZA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C21AFC36-CCD7-4619-9B0D-62B66D674AFB%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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwtifevwFS9N6-%2BKkFVZoStXCokR1JUtYj7J8i3U%2BngZw%40mail.gmail.com.

[evernat]

@Stephen
+1 for PR as this shows which plugins have no maintainers and plugins in the attic space can possibly be hidden in the available plugins (yes, 1000+ plugins is too much to find which plugins can be useful).

@Kanstantsin
Fortunately, the numbers of current installations by plugins are already available and up to date at [1].
These numbers of installations are just waiting for someone to get them and can probably be added to update-center.json [2] by [3] and then displayed in the list of available plugins.

[1] http://stats.jenkins-ci.org/plugin-installation-trend/latestNumbers.json
[2] https://updates.jenkins-ci.org/current/update-center.json
[3] https://github.com/jenkinsci/backend-update-center2

[James Nord]

I would go one further and aswell as the metadata, create an "attic" update center akin to the "experimental" UC.

It's sometimes daunting for a new admin to find that one plugin that may do what he needs from the 1000+ listed...

[Daniel Beck]

On 10.06.2015, at 22:05, James Nord <james...@gmail.com> wrote:

> I would go one further and aswell as the metadata, create an "attic" update center akin to the "experimental" UC.

No way. I use quite a few plugins that haven't seen updates in years and work well, better than several maintained plugins I could mention.

This would also mess with updates to installed plugins after e.g. a core update.

[Daniel Beck]

On 11.06.2015, at 00:01, Daniel Beck <m...@beckweb.net> wrote:

> This would also mess with updates to installed plugins after e.g. a core update.

Or even out of the box. Subversion Plugin, Javadoc Plugin, Ant Plugin, Translation Assistance Plugin, ... don't look like they currently qualify for out-of-attic status.

[John Tatum]

I know I am somewhat new around here, but here is my opinion for whatever it is worth.

I can definitely see value in being able to determine whether or not a plugin is maintained, especially for when somebody is asking to be able to commit to it. I do not think the model proposed would provide a sufficiently accurate representation of that state. To me it would make more sense to evaluate the activity of the maintainer for a given plugin versus the activity on the plugin itself. It might also be worth evaluating other datapoints for the plugin itself such as average life span of pull requests, average number of pull requests in queue, etc.

I am not familiar with the GitHub APIs, so I do not know how difficult that would be to implement. It might also be more accurate to correlate GitHub data with data extracted from Jira or other sources.

I see little if any value in an "attic" for plugins. I have been using Jenkins for quite some time, and many of the plugins I use and have used have gone for extended periods without updates. In my opinion, this does not have any bearing on the suitability of a plugin for the performance of a given task. The idea that a plugin that still has utility is not plainly available within the UC seems like it would cause a great deal of frustration to Jenkins users/administrators.

I think the idea of making certain plugin metadata available in the UC has merit. I think the usefulness of metadata would be enhanced by the ability to filter plugins based on various criteria.

I think a possible reprecussion of a secondary "Attic" UC is the proliferation of non-official UCs. I can see myself (and others) creating my own with everything in it versus having to switch to an alternate to install certain plugins. I cannot imagine that this has long-term benefit to the Jenkins project, or it's users.


John Tatum
john....@live.com
http://scientifichooliganism.net

Although this e-mail and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and/or upon which it is opened, it is the responsibility of the recipient(s) to ensure that it is virus and/or defect free and John Tatum bears no responsibility for any loss and/or damage arising in any way from its use.

[Baptiste Mathus]

Really, I can't help but thinking regularly about that proposal. IMO it's just too simple to not try it. And really it would have value with *very* few downside.

Re-reading the thread, seems like actually there almost a consensus here (only one person being against it).

For example, each time someone asks for commit rights, I have to spend a unreasonable amount of time looking for recent commits dates, who did it, what's in the plugin page, and so on.

With this, we could progressively mark plugins as to-be-adopted hopefully before those requests. It could even encourage potential maintainers to stand up if they see in the wiki page they're reading that a plugin they're using is missing a maintainer. 

And for maintainers, it would really be nothing to do. Something around 10 seconds work every 3 months or so.

(as Stephen said, we'd only require the maintainer to, say, comment "ACK, nope thanks under a few days or weeks, I'm still here", and close the "Maintainer's Ping PR" to know the plugin is not abandoned).

The only thing here is IMO actually to find the right coefficients for the time between those "Maintainer's Ping PR", and the time after which we would consider it unmaintained. And so on.

@Stephen, did you at the time start prototyping something? 

Maybe I'll have a look some day, so if you started something just let me know.

Thanks

--

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/BLU179-W560C64F73D83ECB4D0481FF7BD0%40phx.gbl.

[Nigel Magnay]

This stuff seems very wrong-headed to me, and headed towards exactly the kind of 'governance orgy' I always thought Jenkins eschewed.

Really, I can't help but thinking regularly about that proposal. IMO it's just too simple to not try it. And really it would have value with *very* few downside.

Re-reading the thread, seems like actually there almost a consensus here (only one person being against it).

For example, each time someone asks for commit rights, I have to spend a unreasonable amount of time looking for recent commits dates, who did it, what's in the plugin page, and so on.

​Right - but the issue here is that of centralisation - something that is completely in the opposite direction of the progress that has been made in open source with decentralised tooling. You're describing an unfortunate administrative consequence of living in an old-world centrally-planned economy - hoping a technical fix will somehow solve a social issue. Another, related issue which comes up occasionally is what happens when there are several, "competing" plugins with similar functionality. Who decides if I may have "permission" to start a new plugin that may appear in the UC ? 

If I want to make a change to a plugin, I just fork it and change it. I should be able to make my changed plugin available - easily - for installataion​ (it should have entirely equal "status" to the original plugin). If the original plugin maintainer has 'silently retired' - so be it. People will start migrating to the new fork as it is the one that's 'up to date' - or even just in the interim whilst the 'owner' gets around to merging outstanding PRs (or massaging them into something they find more acceptable).

This is exactly how things like docker images are maintained and shared.

I can give a real example (this pattern has occurred many more than once though). I github forked jenkinsci/robot-plugin to make it compatible with workflow, and submitted a PR to give back the work. In the 6 months or so before it was finally merged, literally every month someone would ask on the original project "is this being merged yet? When will there be a release?". Frankly, I couldn't have cared less if it were merged or not - I can compile plugins, I'd fixed our issue and there was no benefit to me in hassling the original plugin owner. How nice though it would have been to be able to say to others using the plugin something like 'hey, in the short term, if you flip your install from jenkinsci/robot-plugin to magnayn/robot-plugin, that'll get you up and running). 

Yes, you'll need a much richer "update center" / "plugin management" functionality than exists today. Absolutely part of that should be information about plugin "age", jenkins version, maintainer; number of installations.

 

[Michael Neale]

Probably would pick up a lot of repos!

But might also cause some to spring into action (myself included)

[Stephen Connolly]

If only I had the time!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS707Da3jJSNGJp%3D5SFkhNZOuAwyOQd2qPUoq2dpoWU9%3DQ%40mail.gmail.com.