On Wednesday, March 8, 2023 at 1:29:53 AM UTC-7 Jiri Vanek wrote:
On 3/8/23 04:31, Basil Crow wrote: > The main duty of a plugin maintainer from my perspective is to not > introduce regressions for users of the plugin. > Interesting point of view. How about this scenario: - plugin is maintained - I do a PR, adding enhancements - plugin maintainers suggest changes, which actually made regression in plugin - I highlight that, I implement that - year of silence, suddenly the plugin is orphaned - Should I merge my own PR with suggested "regressing" changeset, which was recommended by former maintainers or - as by your advice - roll back to original idea code? Since even experienced maintainers make mistakes and a regressing changeset is generally a mistake, I think you should use the original idea code, since it is better for you and better for other users. Especially junior (and all lazy ones) contributors would definitely follow recommended path, rather then roll back. I made that mistake with a plugin that I adopted a few months ago. It's last release had been done many years ago. I adopted it and made the flawed assumption that the master branch was in good condition, ready to release. I released a new version of the plugin from the master branch and was then dismayed to have reports from users that the new release included a regression. I reverted most of the changes that had been made on the master branch in those intervening years and released a new version of the plugin without those regressions. The existing use cases were much more valuable than the new features that introduced the regression. I think that users were ultimately benefited by the new releases of the plugin, though the regression was a disruption that would have been better to avoid. Another idea - to adopt a plugin usually mean that you are heavily using it. That also usually means that you have some changes in mind, worthy of implementation. And suddenly there is no gate keeper to calm down yours enthusiasm, so it is easy to cause regression which may be hard to fix. I think that is an acceptable risk, especially if the new maintainer is an active user of the plugin. The new maintainer is more likely to respond to reports of a regression than others are. The enthusiasm of the new maintainer moves the plugin forward, even if some of that forward motion may be accompanied by an occasional unintended partial step backwards I didn't find it difficult to revert the changes and fix the regression in the case that I created. Maye to rephrase your sentence: "The main duty of a plugin maintainer is to enjoy the maintenance. It is also important to keep plugin secure, up to date with future jenkins and java. In unlikely case regressions for users of the plugin happens, then to fix it, or at least workaround it" I like the idea of including a comment about enjoying the maintenance effort. Thanks for suggesting it. Mark Waite -- 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/e3d57628-d4c5-48b5-9a58-09921c88c4a8n%40googlegroups.com.
