Plugin Hosting Request: Violations Reboot Plugin
Tomas Bjerre
Richard Bywater
-1 for creating a forked version. If there is an issue with the existing plugin I'd much rather see it being worked on to bring it up to standard rather than creating a completely separate plugin which could lead to confusion amongst users.
My 2 cents...
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/ba38fabe-ff19-4828-a737-d2320ea5681f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tomas Bjerre
domi
Tomas Bjerre
Stephen Connolly
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/63f7a528-5548-412b-a885-5b8bb38ffc1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
Tomas Bjerre
Ok nice! I'll make an attempt at working for a release in the main repo. You can consider the hosting request as revoked.
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/mWUgOZc61KY/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%2BnPnMw0e5tgi89cP%2BZE8%2BOm5ThqSETKm0_CfzYktZbKhXwB7w%40mail.gmail.com.
Baptiste Mathus
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAK89W5%2BNQ_c80Z5DvY0phZ_TiKakyLMVFt-XH176nfhE1VdUug%40mail.gmail.com.
Tomas Bjerre
I tried to but in my opinion it should be re-written completely. A library for parsing reports should be developed in a separate project and used in that new plugin.
The code quality is poor and alot of time is needed to manage all the submitted issues.
So I would actually prefer this plugin being depricated and removed :)
-Tomas
Surya Gaddipati
Nigel Magnay
Can't we let people do what they want instead of forcing people to deal with code they don't want to. We are actively harming jenkins community by overly policing plugins.
- This will be forked into the Jenkins organisation, which will become the canonical source repo
Tomas Bjerre
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!
I tried to get a plugin hosted that would generate a changelog from a git repository. That code eventuelly got added to the git changelog plugin. When I tried to publish my plugin I was denied because it was to similar to the existing plugin. Problem is that the existing plugin had a very different approach. The implementations were so different, a merge would never be possible. The result now is one plugin with duplicated features. And that is confusing for a user!
--
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/mWUgOZc61KY/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/CAPYP83S%2Bp8LtmKgkbSEeMiY-9pb%3Dtx8q95HErC8mZJsdNsm%3DGQ%40mail.gmail.com.
Daniel Beck
On 04.01.2016, at 11:29, Tomas Bjerre <tomas.b...@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!
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.
Christopher Orr
> On 04 Jan 2016, at 12:03, Daniel Beck <m...@beckweb.net> wrote:
> On 04.01.2016, at 11:29, Tomas Bjerre <tomas.b...@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.
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-de...@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.
Baptiste Mathus
Inline.
Le 4 janv. 2016 3:31 PM, "Christopher Orr" <ch...@orr.me.uk> a écrit :
>
> 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.b...@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.. :(
IMO that's a pretty good answer as it reminds the situation is actually not so simple. It's just a matter of balance to me.
When we review hosting requests, we strive to keep the entry barrier as low as possible, as this has always been one of the keys of the Hudson/Jenkins success.
But at the same time, and as the project keeps growing, we try to find that balance between forking anything as-is that get requested and strictly requiring to contribute to existing plugins.
Because as Daniel and Christopher said, and to reuse one term having been used, it might also be harming users when you find 5 variants of the small feature you're looking for and none really works as you'd expect.
All of this can indeed lead to mistakes, as we're all human. But the good news is also that (almost?) nothing is definitive and always can be re-discussed.
-- Baptiste