Jochen is a colleague of Stefan Brausch at 1&1 and they maintain a dozen plugins or so, including Job Config History. I doubt this plugin being abandoning is going to be a problem.
This also seems to ask the wrong question -- what we need is better tools for dealing with 1000+ plugins, because no matter how hard we try, that number isn't going to go down. And that would make the issue of 'similar' plugins much less of an issue. So, what problems have been mentioned? - Too many plugins. We need better UI and tools to deal with that many plugins rather than not admitting new ones. - Similar plugins. Nothing really wrong with that. They shouldn't be identical, but Build Timeout and Logfilesizechecker both abort builds. No reason that both shouldn't exist. - Abandoned plugins. I think we're fairly safe from that POV as I mentioned above. That said, this plugin is a 'one trick pony' with little maintenance to begin with, and if it ever breaks, what really is lost? It doesn't look like it has that much to contribute to the Old Data Monitor, it wouldn't break your builds, … Let's face it, different plugins require different maintenance effort, and this is a low maintenance one. While I can imagine this plugin getting merged into another one, I don't think it's necessary if the author disagrees. On 24.07.2015, at 08:24, domi <[email protected]> wrote: > IMO, History has shown that maintenance will more likely not been maintained. > …sure, everyone wants his own plugin, but its not the best for the community > and the endusers too > my 2 cents... > > On 24 Jul 2015, at 08:03, Jochen-A-Fuerbacher <[email protected]> > wrote: > >> Does ist really reduce the risk of bad maintained plugins? I don't think so. >> When merging plugins then the risk is higher that none of the features will >> get maintained any longer. But when the features are implemented in own >> plugins, then maybe some of the plugins aren't maintained, but some others >> are. >> >> >> Åsmund Østvold wrote >>> I like the destination of the plugin but.... >>> As the number of jobs grow the number of plugins grow. Many plugins are >>> not maintained for a long period. Keeping similar features in one plugin >>> reduce the risk of this happening. This increase the ease of use and >>> administration of a Jenkins installation. >>> >>> IMHO +1 for integration >> >> >> >> >> >> -- >> View this message in context: >> http://jenkins-ci.361315.n4.nabble.com/Request-hosting-a-plugin-tp4761476p4761925.html >> Sent from the Jenkins dev mailing list archive at Nabble.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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/1437717839669-4761925.post%40n4.nabble.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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/57127380-9162-4188-BF93-87D7B3AF8830%40fortysix.ch. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9580207A-69F0-4B27-B3ED-F9CA3C174F23%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
