Removed as JIRA project lead of ruby-runtime-plugin
I am still the lead on https://issues.jenkins-ci.org/browse/JENKINS/component/16320/ but I have not maintained the plugin for some time. The plugin wiki page lists two new maintainers that could possibly be candidates: https://wiki.jenkins-ci.org/display/JENKINS/Ruby+Runtime+Plugin SHIBATA Hiroshi (id: hsbt) YAMASHITA Yuu (id: yyuu) Any chance I could be removed from the JIRA component? Thank you. - Jørgen. -- 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/CAN%2BHQN1V4meZfd8eM0KcGTkCOn1BwtfuDnhbxV6EsKZU0aTpFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Removed as JIRA project lead of ruby-runtime-plugin
Tyler: Sweet, thank you. Can you de-lead (heh heh) me from https://issues.jenkins-ci.org/browse/JENKINS/component/16135/ too? Baptiste, https://wiki.jenkins-ci.org/display/JENKINS/Pathignore+Plugin should probably be marked as an adoptable plugin too. -- 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/09ee7b73-5c0f-4a80-93a6-af2dd18a48e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Granting access to a plugin repository
(Trying this again after rejoining jenkinsci-dev.) Could someone please grant commit access to jenkinsci/environment-script-plugin to https://github.com/dawidmalina? I have not worked on the plugin for three years, and I have not been using it for at least two, so it's about time someone else took over, and Dawid has expressed interest in updating it. Thank you! (Please include Dawid in CC on replies, as I don't know if he subscribes to jenkinsci-dev.) - Jørgen. -- 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/CAN%2BHQN27MR5v_XMEMdGguCmbEk2RJdfV7J0hFN%2BUJZ6LtMB3GA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [RFC] publishers as a drop-down menu
On Wed, Apr 25, 2012 at 11:06 PM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: On 04/19/2012 02:50 PM, Jørgen Tjernø wrote: With a few changes to make it so that build tasks could behave like post-build tasks (always run as opposed to don't run if build failed, etc), it seems feasible to me. The benefit would be a simpler UI, simpler codebase and the opportunity for more re-use. The complexity of the Jenkins codebase is definitely significant for new people to start developing - both plugins core changes. Because of the backward compatibility requirements, I suspect this change is likely add to more complexity, at least for a short term. That is not to say we shouldn't do it. but it'd have the opposite effect for 100 or 200 releases to come until we retire the old abstractions. That makes sense - another possibility would be to rearchitect this completely, then write a compatibility layer that goes between old plugins and the core (or have a special case for old plugins in the core). That way the code path for new plugins would be clean, and we could eventually deprecate the compat layer. On the broader issue of the complexity, maybe we can actually start deleting some code that's marked deprecated long enough. Do you think those would help? Or do you see the complexity in places other than compatibility related things? I agree that we should remove deprecated code, but I think the complexity I am the most bothered by is in the code paths that are still encouraged. There are just a *lot* of different abstractions and concepts in core. -- Jørgen.
