Hi Daniel, Thanks for the amendment! Would it be also possible to add an "Announcement" section to reasoning and explicitly document why proposals (blogpost, administrative warning, direct maintainer notification) are rejected?
I still disagree with the user notification approach taken in this proposal, and I believe we should do the best possible effort to notify users. Spending 1 hour to write a blogpost with heads-up and workaround guidelines (and invitations to contribute) is the most obvious way to do that. I do not understand why there is so much resistance about that. CCing all known plugin maintainers in this thread is another obvious way to make them aware of the thread. We cannot expect that any plugin maintainer carefully reads every thread in the mailing list. "Scriptler, Build Flow, Copy to Slave, or Perforce." > I do not buy that justification for JEP-7. All these plugins have been depublished due to security reasons, so there was no way to properly notify users in advance. But even in such case, the users know about the incoming security release in advance so they can prepare to mitigate breaking changes. Maintainers also got directly contacted, and they acknowledged the action. Here you propose to depublish a bunch of non-healthy-but-operational plugins, and the proposed notification process is "let's just do that, they should have read mailing lists". And there are low-cost ways to let users know in advance and to soften the change. I cannot agree with such approach, sorry. Best regards, Oleg On Thursday, August 16, 2018 at 9:45:33 PM UTC+2, Daniel Beck wrote: > > > > On 16. Aug 2018, at 19:45, Oleg Nenashev <[email protected] > <javascript:>> wrote: > > > >> You mean, so that _new_ users can _install_ the plugins? I would say > no. > > > > How would you define a "new" user in the new configuration-as-code > world? If somebody uses official Jenkins Docker image with plugins.txt, the > plugins will fail to install when you rebuild the image after the change > gets deployed. And it is a pretty popular approach nowadays. Plugin > installation features in JCasC 1.0 RC would be also affected AFAICT. > > As of last count, 111 installs of CasC plugin. I'd be _very_ surprised if > this ended up affecting more than 5 systems total. > > And while this isn't the only approach to configuration-as-code, people > should not expect us to continue distributing plugins indefinitely after we > blacklisted the likes of Scriptler, Build Flow, Copy to Slave, or Perforce. > > Notably, update sites only have the newest release, which isn't suitable > for C-as-C anyway, so I expect the more stable approaches to use our Maven > repo anyway -- which will not be affected. > > Running one's own Maven repo has been an important best practice for a > long time. With C-as-C, running one's own update site should be similar. > > I will amend the JEP to record this concern and the answers. I don't think > we need to change anything about the chosen approach. > > -- 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/34ef7c17-96ac-469e-acc2-e1ceb74c92ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
