Hi all, > On 04 Jan 2016, at 12:03, Daniel Beck <m...@beckweb.net> wrote: > On 04.01.2016, at 11:29, Tomas Bjerre <tomas.bjerr...@gmail.com> wrote: >> I am also developing plugins for Stash/Bitbucket Server and I must say that >> their approach is much better. They have the Atlassian Marketplace where >> plugins are published if they have a clear use case, the people at Atlassia >> can successfully test that use case and it is documented properly. >> >> Having somilar plugins is a good thing. Then there will be competition! > > FWIW I'm starting to wonder about this. It's definitely useful in the case of > accidental duplication, i.e. as a checklist item on the "So you want to write > a plugin" page, as well as pointing plugin authors to the similar plugins > once they request hosting -- some have then abandoned their efforts and moved > to the existing plugin once someone pointed them there -- but refusing > hosting for a plugin that already exists? This probably shouldn't happen.
I’m really not sure about this yet — when the discussions started about revamping plugin discovery and users being able to rate them etc., I could see that it might be a good thing to accept every plugin request, regardless of whether there are already existing similar plugins — competition is good. On the other hand, having actually tried to use Jenkins lately, I’ve had an absolutely disastrous experience. I created a new Jenkins instance on my machine to try and replicate part of a production environment, so I installed various plugins we use for Git, GitHub, pull-request building and so on, along with some workflow / multibranch / GitHub stuff. In the end, I couldn’t get Jenkins to do what I needed — I gave up when I couldn’t figure out which of FOUR separate places to enter GitHub credentials I should use — three of which were on the global settings page, and none were fully documented — nor *which* credentials type was required. In addition, it was often unclear which plugin was even providing the UI (the “(from X plugin)” text that shows up in help fields is sometimes useful, *if* the plugin has help text). Last week, I tried to use three separate plugins (unrelated to GitHub this time), and NONE of them worked due to various bugs, and took a long time to even get set up due to poor documentation. It was a *really* depressing experience. With near-zero quality control, more and more overlapping plugins being written, maintainers being unaware of each other, or not wanting to cooperate, it seems like this will only get worse for users — so that’s an argument *for* refusing some hosting requests. On the other hand, developing Jenkins plugins is a bit of a thankless task, so I can appreciate that we should maybe be nicer to plugin developers. But plugin developers are strongly outnumbered by Jenkins users, who appear to be having a rough time, so I’d rather prioritise them having a good experience over developers (though yes, ideally we should make both camps happy somehow). However, if the barrier is too high for people to take over or even improve existing plugins due to bad code, or too many bugs or whatever (the EC2 plugin has one open bug for every 15 users), maybe it does make sense to allow newcomers to write overlapping plugins or rewrites of existing plugins, and enable competition. But in this case, the discovery and review / rating stuff really needs to be in place for end users, there needs to be more clarity about which UI comes from which plugins (so users can try competing plugins, then disable the useless ones), and there somehow needs to be (way more) documentation on plugin development best practices (i.e. don’t re-invent credentials, or the IM plugin, or whatever), and somehow we need to split out more stuff into libraries (e.g. GitHub / Docker / SSH / whatever server configuration). I guess that was a long and ranty way of saying I don’t have a good answer as to what we should be doing with plugins.. :( Regards, Chris > OTOH, there are a few arguments _for_ this, and I'd like to get your take on > these: > > * Plugins get abandoned, but remain compatible with Jenkins for a long time. > AFAIU, Atlassian plugins often need to be replaced with a major version > update (at least I had acquaintances complain about how much effort some > major version updates are because plugins aren't compatible), so there seems > to be less chance of something that isn't actively maintained to linger > forever. > * We emphasize community contributions compared to individual ownership. That > doesn't mean that the latter isn't possible, or even that it's discouraged, > but we'd like to have someone be able to take over in case the original > maintainer disappears or loses interest. > * Users (and developers) complain about some clusters of plugins with similar > or overlapping features. > > -- > 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-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/A801AED8-5848-45F3-BEF1-0B172B230B5A%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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D99CEA86-7985-4129-8B07-DD9323114484%40orr.me.uk. For more options, visit https://groups.google.com/d/optout.
