Re: Discussion: Refactoring of JENKINS project in JIRA
Update on Components refactoring: - All required commands have been added to Jenkins IRC Bot (see https://wiki.jenkins-ci.org/display/JENKINS/IRC+Bot) - Major core components have been renamed and merged (see the status on https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring) - Plugins modifications: in progress (background activity); https://issues.jenkins-ci.org/browse/INFRA-147 would be very useful, but a public announcement is required пятница, 5 сентября 2014 г., 11:55:02 UTC+4 пользователь Tom Fennelly написал: Hi Richard. Would be no problem adding that - would be the same basic process. I think we need to be careful not to add to many Important notices as that may just lead to people not reading any of them. On Thursday, September 4, 2014 3:02:28 PM UTC+1, Richard Mortimer wrote: Hi, On 04/09/2014 13:22, Tom Fennelly wrote: At yesterdays governance meeting on #jenkins we talked about configuring JIRA to provide some helpful text wrt the Components and Labels fields to help people file issues more consistently. We talked about doing it using Javascript hacks. I installed a trial JIRA and was able to configure the fields easily enough. I moved the Components and Labels fields together on the form and configured some bright ( ;) ) help text on each field. * Here's a screenshot of what it can look like https://www.dropbox.com/s/kn7mc5qzyk9gfwn/Screenshot%202014-09-04%2013.04.05.png?dl=0. * Here's the JIRA: https://issues.jenkins-ci.org/browse/INFRA-123 Looks good to me. Possible text edits aside, I think this should help. Along similar lines... Is it possible to add some text to remind people that JIRA is intended for reporting bugs and rfes. There is a steady stream of people who seem to report their setup/configuration questions in JIRA rather than asking via email or IRC. Maybe add some text to the Issue Type field along the following lines to point people at the proper support forums: Important: This issue tracker is intended to track bugs and enhancements to Jenkins. Questions regarding configuration and operation of Jenkins should be directed towards jenkins...@googlegroups.com or the #jenkins channel (http://jenkins-ci.org/content/chat) on IRC. Regards 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
At yesterdays governance meeting on #jenkins we talked about configuring JIRA to provide some helpful text wrt the Components and Labels fields to help people file issues more consistently. We talked about doing it using Javascript hacks. I installed a trial JIRA and was able to configure the fields easily enough. I moved the Components and Labels fields together on the form and configured some bright ( ;) ) help text on each field. - Here's a screenshot of what it can look like https://www.dropbox.com/s/kn7mc5qzyk9gfwn/Screenshot%202014-09-04%2013.04.05.png?dl=0 . - Here's the JIRA: https://issues.jenkins-ci.org/browse/INFRA-123 Possible text edits aside, I think this should help. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
Hi, On 04/09/2014 13:22, Tom Fennelly wrote: At yesterdays governance meeting on #jenkins we talked about configuring JIRA to provide some helpful text wrt the Components and Labels fields to help people file issues more consistently. We talked about doing it using Javascript hacks. I installed a trial JIRA and was able to configure the fields easily enough. I moved the Components and Labels fields together on the form and configured some bright ( ;) ) help text on each field. * Here's a screenshot of what it can look like https://www.dropbox.com/s/kn7mc5qzyk9gfwn/Screenshot%202014-09-04%2013.04.05.png?dl=0. * Here's the JIRA: https://issues.jenkins-ci.org/browse/INFRA-123 Looks good to me. Possible text edits aside, I think this should help. Along similar lines... Is it possible to add some text to remind people that JIRA is intended for reporting bugs and rfes. There is a steady stream of people who seem to report their setup/configuration questions in JIRA rather than asking via email or IRC. Maybe add some text to the Issue Type field along the following lines to point people at the proper support forums: Important: This issue tracker is intended to track bugs and enhancements to Jenkins. Questions regarding configuration and operation of Jenkins should be directed towards jenkinsci-us...@googlegroups.com or the #jenkins channel (http://jenkins-ci.org/content/chat) on IRC. Regards 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
On 4 September 2014 15:02, Richard Mortimer ri...@oldelvet.org.uk wrote: Hi, On 04/09/2014 13:22, Tom Fennelly wrote: At yesterdays governance meeting on #jenkins we talked about configuring JIRA to provide some helpful text wrt the Components and Labels fields to help people file issues more consistently. We talked about doing it using Javascript hacks. I installed a trial JIRA and was able to configure the fields easily enough. I moved the Components and Labels fields together on the form and configured some bright ( ;) ) help text on each field. * Here's a screenshot of what it can look like https://www.dropbox.com/s/kn7mc5qzyk9gfwn/Screenshot% 202014-09-04%2013.04.05.png?dl=0. * Here's the JIRA: https://issues.jenkins-ci.org/browse/INFRA-123 Looks good to me. Possible text edits aside, I think this should help. Along similar lines... Is it possible to add some text to remind people that JIRA is intended for reporting bugs and rfes. There is a steady stream of people who seem to report their setup/configuration questions in JIRA rather than asking via email or IRC. Maybe add some text to the Issue Type field along the following lines to point people at the proper support forums: Important: This issue tracker is intended to track bugs and enhancements to Jenkins. Questions regarding configuration and operation of Jenkins should be directed towards jenkinsci-us...@googlegroups.com or the #jenkins channel (http://jenkins-ci.org/content/chat) on IRC. Maybe we could add a stupid captcha that forces you to enter the text I am creating this because I either found a bug or have an idea for an improvement before you can create the issue ;-) (Nobody reads the screen from what I can see) Regards 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-dev+unsubscr...@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
Update on Action #1.b: - The Wiki page seems to be finalized (in the scope of component changes) - All actions seem to be categorized - There were many contributions from other people - No unhandled comments from the mailing list/IRC - No new comments over 1 month - I've started the update of Jenkins IRC Bot in order to simplify the modification process: - Issue on Jenkins JIRA: https://issues.jenkins-ci.org/browse/INFRA-100 - https://github.com/jenkins-infra/ircbot/pull/11 - https://github.com/jenkinsci/lib-jira-scraper/pull/1 - Unfortunately, there's no responses. I have no JIRA installations to test new jira-scraper routines - Workflow changes: Untriaged and Waiting on requester states - The description has not been finalized yet - BTW, both states have been discussed in IRC/mailing list. There should not be any blockers Best regards, Oleg Nenashev 2014-08-06 9:32 GMT+04:00 Oleg Nenashev o.v.nenas...@gmail.com: Summary from the previous Project meeting (thanks to Daniel Beck for the notification). 1. *JIRA components* (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-59, 18:18:39) 1. https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring (danielbeck http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-62, 18:19:33) 2. *ACTION*: oleg-nenashev to report on status of JIRA component change (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-72, 18:22:31) 3. *ACTION*: kohsuke to implement JIRA component change (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-73, 18:22:39) 4. *AGREED*: want unsorted component empty, but maybe need a more descriptive name (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-99, 18:27:51) 2. *JIRA components* (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-106, 18:29:07) 1. *ACTION*: oleg-nenashev to document intended usage of unsorted ( jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-113, 18:31:13) I'll try to send a summary on my actions in advance. BR, Oleg Nenashev вторник, 24 июня 2014 г., 21:37:43 UTC+4 пользователь Oleg Nenashev написал: Since there's no additional input on the components modification, I propose to apply changes on JIRA. Thanks to R. Tyler and OSUOSL, Jenkins JIRA is stable enough for such changes now. If everyone agrees, it would be great if somebody with JIRA administration rights takes the action point. Actions backlog: - Describe the workflow modification for JIRA project - Untriaged state for new issues (see Kohsuke's clarification above) - [New] - Waiting on user state - for incomplete issues Best regards, Oleg Nenashev 2014-06-10 18:41 GMT+04:00 Jesse Glick jgl...@cloudbees.com: On Tue, Jun 10, 2014 at 3:34 AM, Daniel Beck m...@beckweb.net wrote: Confused it with the Maven build step that's part of core. (but which ought to be a plugin too) -- 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/luOqm4Qj4sc/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/luOqm4Qj4sc/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
Summary from the previous Project meeting (thanks to Daniel Beck for the notification). 1. *JIRA components* (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-59, 18:18:39) 1. https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring (danielbeck http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-62, 18:19:33) 2. *ACTION*: oleg-nenashev to report on status of JIRA component change (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-72, 18:22:31) 3. *ACTION*: kohsuke to implement JIRA component change (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-73, 18:22:39) 4. *AGREED*: want unsorted component empty, but maybe need a more descriptive name (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-99, 18:27:51) 2. *JIRA components* (jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-106, 18:29:07) 1. *ACTION*: oleg-nenashev to document intended usage of unsorted ( jglick http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-07-23-18.02.log.html#l-113, 18:31:13) I'll try to send a summary on my actions in advance. BR, Oleg Nenashev вторник, 24 июня 2014 г., 21:37:43 UTC+4 пользователь Oleg Nenashev написал: Since there's no additional input on the components modification, I propose to apply changes on JIRA. Thanks to R. Tyler and OSUOSL, Jenkins JIRA is stable enough for such changes now. If everyone agrees, it would be great if somebody with JIRA administration rights takes the action point. Actions backlog: - Describe the workflow modification for JIRA project - Untriaged state for new issues (see Kohsuke's clarification above) - [New] - Waiting on user state - for incomplete issues Best regards, Oleg Nenashev 2014-06-10 18:41 GMT+04:00 Jesse Glick jgl...@cloudbees.com: On Tue, Jun 10, 2014 at 3:34 AM, Daniel Beck m...@beckweb.net wrote: Confused it with the Maven build step that's part of core. (but which ought to be a plugin too) -- 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/luOqm4Qj4sc/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
Since there's no additional input on the components modification, I propose to apply changes on JIRA. Thanks to R. Tyler and OSUOSL, Jenkins JIRA is stable enough for such changes now. If everyone agrees, it would be great if somebody with JIRA administration rights takes the action point. Actions backlog: - Describe the workflow modification for JIRA project - Untriaged state for new issues (see Kohsuke's clarification above) - [New] - Waiting on user state - for incomplete issues Best regards, Oleg Nenashev 2014-06-10 18:41 GMT+04:00 Jesse Glick jgl...@cloudbees.com: On Tue, Jun 10, 2014 at 3:34 AM, Daniel Beck m...@beckweb.net wrote: Confused it with the Maven build step that's part of core. (but which ought to be a plugin too) -- 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/luOqm4Qj4sc/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
On 10.06.2014, at 07:09, Oleg Nenashev o.v.nenas...@gmail.com wrote: https://github.com/jenkinsci/ant-plugin Sorry about that. Confused it with the Maven build step that's part of core. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
On Tue, Jun 10, 2014 at 3:34 AM, Daniel Beck m...@beckweb.net wrote: Confused it with the Maven build step that's part of core. (but which ought to be a 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
We have maven and maven2 for no good reason, so the latter is on the kill list as well. maven2 = maven-plugin hudson-logaction and logaction seem to be the same component, so one must go. logaction-plugin is a proper name Also provided a list of all non-plugin components not currently scheduled to be changed, more as a reference for further component murder than any particular desire to not see them modified. I've created the additional section for abstract components, which require complex actions (security, concurrent-build, ant, etc.). Currently, the section include only cli and core components - slave-setup was a false positive, it's a plugin (the one I actually meant when I suggested 'master-slave' as an example for a plugin component not looking like a plugin in IRC during the meeting a while back!). - added the XXX to XXX-plugin component rename suggestion Removed the slave-setup entry - I added a list of plugin components missing the usual comment to indicate they're a plugin. This might well be obsolete with the -plugin rename, in which case all plugin components should have their (then redundant) descriptions removed to keep the components list clean (and a description should be mandatory for all components that aren't plugins). Thanks! Unfortunately, we cannot just rename GitHub repositories I think the Untriaged state part needs more explanation and attention, This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. It makes sense to re-work the text and put it on the Wiki page. The text should be placed on https://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking after the workflow modification. I also think that somebody should describe required infrastructure changes and create appropriate INFRA issues. Examples: - Create JIRA components according to GitHub repository names instead of the plugin IDs - IRC Bot (?): Ensure that new plugin repositories have the -plugin suffix - ... Best regards, Oleg Nenashev пятница, 6 июня 2014 г., 5:56:51 UTC+4 пользователь Kohsuke Kawaguchi написал: I think the Untriaged state part needs more explanation and attention, because the intention behind this change is to encourage coreplugin developers to change the workflow. The idea is that issues in this state is not confirmed/accepted by developers. I think the expectation is that developers would go through untriaged issues quickly and check if they seem to contain enough information (if not, close it and let the submitter reopen with more info), if it's filed against the right component (if not, reclassify), etc. And if it appears to be a serious issue, we want to flag it and make sure it gets worked on in a timely manner. To me, a part of the motivation for this new state is that it lets us ensure that issues are touched and notice serious issues sooner than later. This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. On 06/04/2014 11:41 AM, Oleg Nenashev wrote: Hello, This is a follow-up to the discussion of Jenkins JIRA issues (IRC, #jenkins, May 28th). I've created a page on Jenkins Wiki, which aggregates all discussed proposals. URL: https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring This page is a publicly accessible draft. Any additional comments and proposals will be appreciated. Best regards, Oleg Nenashev -- 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 javascript: mailto:jenkinsci-dev+unsubscr...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
To rename a github repo, you can just fork it to a new name within the same org. I did this with the emailext - template - plugin. On Jun 9, 2014 1:12 PM, Oleg Nenashev o.v.nenas...@gmail.com wrote: We have maven and maven2 for no good reason, so the latter is on the kill list as well. maven2 = maven-plugin hudson-logaction and logaction seem to be the same component, so one must go. logaction-plugin is a proper name Also provided a list of all non-plugin components not currently scheduled to be changed, more as a reference for further component murder than any particular desire to not see them modified. I've created the additional section for abstract components, which require complex actions (security, concurrent-build, ant, etc.). Currently, the section include only cli and core components - slave-setup was a false positive, it's a plugin (the one I actually meant when I suggested 'master-slave' as an example for a plugin component not looking like a plugin in IRC during the meeting a while back!). - added the XXX to XXX-plugin component rename suggestion Removed the slave-setup entry - I added a list of plugin components missing the usual comment to indicate they're a plugin. This might well be obsolete with the -plugin rename, in which case all plugin components should have their (then redundant) descriptions removed to keep the components list clean (and a description should be mandatory for all components that aren't plugins). Thanks! Unfortunately, we cannot just rename GitHub repositories I think the Untriaged state part needs more explanation and attention, This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. It makes sense to re-work the text and put it on the Wiki page. The text should be placed on https://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking after the workflow modification. I also think that somebody should describe required infrastructure changes and create appropriate INFRA issues. Examples: - Create JIRA components according to GitHub repository names instead of the plugin IDs - IRC Bot (?): Ensure that new plugin repositories have the -plugin suffix - ... Best regards, Oleg Nenashev пятница, 6 июня 2014 г., 5:56:51 UTC+4 пользователь Kohsuke Kawaguchi написал: I think the Untriaged state part needs more explanation and attention, because the intention behind this change is to encourage coreplugin developers to change the workflow. The idea is that issues in this state is not confirmed/accepted by developers. I think the expectation is that developers would go through untriaged issues quickly and check if they seem to contain enough information (if not, close it and let the submitter reopen with more info), if it's filed against the right component (if not, reclassify), etc. And if it appears to be a serious issue, we want to flag it and make sure it gets worked on in a timely manner. To me, a part of the motivation for this new state is that it lets us ensure that issues are touched and notice serious issues sooner than later. This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. On 06/04/2014 11:41 AM, Oleg Nenashev wrote: Hello, This is a follow-up to the discussion of Jenkins JIRA issues (IRC, #jenkins, May 28th). I've created a page on Jenkins Wiki, which aggregates all discussed proposals. URL: https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+ Components+Refactoring This page is a publicly accessible draft. Any additional comments and proposals will be appreciated. Best regards, Oleg Nenashev -- 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 mailto:jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
Ant is not in a plugin, so renaming 'ant' to 'ant-plugin' would just be confusing. The same applies to 'cli' -- they are both (currently) part of jenkins.war, so should probably be merged into 'core'. - I added a list of plugin components missing the usual comment to indicate they're a plugin. This might well be obsolete with the -plugin rename, in which case all plugin components should have their (then redundant) descriptions removed to keep the components list clean (and a description should be mandatory for all components that aren't plugins). Thanks! Unfortunately, we cannot just rename GitHub repositories That's about Jira, not Github. It seems that plugin component names in Jira by convention have a description containing 'plugin', see https://issues.jenkins-ci.org/browse/JENKINS#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel -- but some are exceptions, and that's what that is about. Also, GitHub repos can be renamed -- I've done it. Is there a restriction (e.g. only repos that are not yet an certain age, or not too popular, ...) or why do you write we cannot do that? I think the Untriaged state part needs more explanation and attention, This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. We should also look into changing the description, as it specifically refers to security issues (as does 'Fix Prepared'). No idea whether this is configurable. * IRC Bot (?): Ensure that new plugin repositories have the -plugin suffix Probably sufficient to add a note on http://wiki.jenkins-ci.org/display/JENKINS/IRC+Bot how to name plugin repos. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
Ant is not in a plugin, so renaming 'ant' to 'ant-plugin' would just be confusing. The same applies to 'cli' -- they are both (currently) part of jenkins.war, so should probably be merged into 'core'. https://github.com/jenkinsci/ant-plugin BTW, there're some core-related issues, hence I propose to use the Untriaged state to review issues Also, GitHub repos can be renamed -- I've done it. Is there a restriction (e.g. only repos that are not yet an certain age, or not too popular, ...) or why do you write we cannot do that? I agree, the GitHub repos renaming is not a part of the thread. Just an off-topic... The renaming was a non-recommended operation on GitHub for a long time, but seems it works well now. In addition to redirecting web traffic, all git clone, git fetch, or git push operations targeting the previous location will continue to function as if made on the new location ( https://help.github.com/articles/renaming-a-repository). Seems that renaming is safe for users and automation flows. We could try the renaming on several unpopular plugins like *junit-realtime-test-reporter*. We could also fork a repo according to comments from Alex, but all user forks will reference the initial repo = there will be additional efforts to adjust the security and to handle pull-requests to legacy repositories. The renaming seems to be preferable if it works well. 2014-06-10 1:16 GMT+04:00 Daniel Beck m...@beckweb.net: Ant is not in a plugin, so renaming 'ant' to 'ant-plugin' would just be confusing. The same applies to 'cli' -- they are both (currently) part of jenkins.war, so should probably be merged into 'core'. - I added a list of plugin components missing the usual comment to indicate they're a plugin. This might well be obsolete with the -plugin rename, in which case all plugin components should have their (then redundant) descriptions removed to keep the components list clean (and a description should be mandatory for all components that aren't plugins). Thanks! Unfortunately, we cannot just rename GitHub repositories That's about Jira, not Github. It seems that plugin component names in Jira by convention have a description containing 'plugin', see https://issues.jenkins-ci.org/browse/JENKINS#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel -- but some are exceptions, and that's what that is about. Also, GitHub repos can be renamed -- I've done it. Is there a restriction (e.g. only repos that are not yet an certain age, or not too popular, ...) or why do you write we cannot do that? I think the Untriaged state part needs more explanation and attention, This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. We should also look into changing the description, as it specifically refers to security issues (as does 'Fix Prepared'). No idea whether this is configurable. * IRC Bot (?): Ensure that new plugin repositories have the -plugin suffix Probably sufficient to add a note on http://wiki.jenkins-ci.org/display/JENKINS/IRC+Bot how to name plugin repos. -- 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/luOqm4Qj4sc/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
stapler, winsw, are fine insofar as these are just repositories outside
@jenkinsci; of
course core needs to integrate new releases of these components to
pick up fixes, but that generally does not need its own issue
The main idea was to group existing issues related to these components.
Even if there are external Bug trackers, it's hard to categorize related
issues within the Jenkins JIRA and to propagate them to proper bugtrackers.
Probably, labels could be enough
I would suggest that the JIRA component name exactly match the
repository name in all cases, specifically meaning that we should use
git-plugin rather than git, etc
Actually, there's a naming hell in GitHub as well. Many plugin repos do not
have the -plugin suffix. GitHub names could be also unfriendly to users,
because the pluginId is a single option available on plugin Wiki pages.
What about the reverse notation, which could visually group all plugins?
E.g. *plugin-${pluginId/GithubName}*
hudson.sfbay is presumably obsolete, seeing as this Sun Microsystems
intranet domain no longer exists. :-)
There're 16 issues for this case. Should we just close them?
Regarding native-rpm etc., I would leave these in core for the time being
I think we could make an exception in this case and to create components
before the decoupling.
2014-06-05 0:05 GMT+04:00 Jesse Glick jgl...@cloudbees.com:
On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev o.v.nenas...@gmail.com
wrote:
Any additional comments and proposals will be appreciated.
I would not make an exception to the rule that “only a single
component per GitHub repository should exist. stapler, winsw, are
fine insofar as these are just repositories outside @jenkinsci; of
course core needs to integrate new releases of these components to
pick up fixes, but that generally does not need its own issue. (Note
that some of these repos have their own GH issue trackers.)
I would suggest that the JIRA component name exactly match the
repository name in all cases, specifically meaning that we should use
git-plugin rather than git, etc. (Originally I was thinking that the
plugin artifactId/shortName should match the component, but using the
repository name makes it clearer what is a plugin vs. some other
library, and gives us better consistency overall.)
hudson.sfbay is presumably obsolete, seeing as this Sun Microsystems
intranet domain no longer exists. :-)
Regarding native-rpm etc., I would leave these in core for the time
being (with an appropriate label), but it would be great to see these
be split into their own repositories with their own lifecycles. (This
would also be a boon to anyone making an OEM distribution of Jenkins,
as CloudBees does, since you would expect the native packaging to just
take any Jenkins WAR file as an input.)
--
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/luOqm4Qj4sc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
jenkinsci-dev+unsubscr...@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
On 05.06.2014, at 21:22, Oleg Nenashev o.v.nenas...@gmail.com wrote:
Actually, there's a naming hell in GitHub as well. Many plugin repos do not
have the -plugin suffix.
No reason to keep them like this. Github redirects you if you rename something,
so cleanup should be possible without too much hassle.
Also, it's probably only a few dozen plugins or so without that suffix: ~100 of
1200+ repos don't have a commonly used prefix (backend-, extras-, lib-) or
suffix (-module, -plugin). Many of them aren't plugins (jexl, winstone,
trilead-ssh2, xstream, dom4j, jmdns, jna, remoting, ...). Doesn't seem too bad,
and certainly no reason to not make Jira easier to use.
What about the reverse notation, which could visually group all plugins? E.g.
plugin-${pluginId/GithubName}
Autocomplete only works from the beginning. No 'matrix-project' suggestion when
you type 'project'.
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
I changed some things in the wiki: https://wiki.jenkins-ci.org/pages/diffpages.action?pageId=72778066originalId=72778107 - We have maven and maven2 for no good reason, so the latter is on the kill list as well. - hudson-logaction and logaction seem to be the same component, so one must go. - Also provided a list of all non-plugin components not currently scheduled to be changed, more as a reference for further component murder than any particular desire to not see them modified. - slave-setup was a false positive, it's a plugin (the one I actually meant when I suggested 'master-slave' as an example for a plugin component not looking like a plugin in IRC during the meeting a while back!). - added the XXX to XXX-plugin component rename suggestion - I added a list of plugin components missing the usual comment to indicate they're a plugin. This might well be obsolete with the -plugin rename, in which case all plugin components should have their (then redundant) descriptions removed to keep the components list clean (and a description should be mandatory for all components that aren't plugins). On 04.06.2014, at 20:41, Oleg Nenashev o.v.nenas...@gmail.com wrote: Hello, This is a follow-up to the discussion of Jenkins JIRA issues (IRC, #jenkins, May 28th). I've created a page on Jenkins Wiki, which aggregates all discussed proposals. URL: https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring This page is a publicly accessible draft. Any additional comments and proposals will be appreciated. Best regards, Oleg Nenashev -- 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. 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
On 06/04/2014 01:05 PM, Jesse Glick wrote: On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev o.v.nenas...@gmail.com wrote: Any additional comments and proposals will be appreciated. I would not make an exception to the rule that “only a single component per GitHub repository should exist. +1. No matter how we classify things, there will be some pain, so might as well stick to the simplest one. Also +1 for naming components the same as repository names. I think it makes the automation easier, and really that's the only way to manage 900+ plugin project. I would suggest that the JIRA component name exactly match the repository name in all cases, specifically meaning that we should use git-plugin rather than git, etc. (Originally I was thinking that the plugin artifactId/shortName should match the component, but using the repository name makes it clearer what is a plugin vs. some other library, and gives us better consistency overall.) hudson.sfbay is presumably obsolete, seeing as this Sun Microsystems intranet domain no longer exists. :-) This was what I used to track problems/tasks for my deployment called hudson.sfbay.sun.com. So we can just close any pending issues and consider them obsolete. -- Kohsuke Kawaguchi http://kohsuke.org/ -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
I think the Untriaged state part needs more explanation and attention, because the intention behind this change is to encourage coreplugin developers to change the workflow. The idea is that issues in this state is not confirmed/accepted by developers. I think the expectation is that developers would go through untriaged issues quickly and check if they seem to contain enough information (if not, close it and let the submitter reopen with more info), if it's filed against the right component (if not, reclassify), etc. And if it appears to be a serious issue, we want to flag it and make sure it gets worked on in a timely manner. To me, a part of the motivation for this new state is that it lets us ensure that issues are touched and notice serious issues sooner than later. This is a metric we can track to identify plugins that need love, and measure how far behind we've fallen in the core. On 06/04/2014 11:41 AM, Oleg Nenashev wrote: Hello, This is a follow-up to the discussion of Jenkins JIRA issues (IRC, #jenkins, May 28th). I've created a page on Jenkins Wiki, which aggregates all discussed proposals. URL: https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring This page is a publicly accessible draft. Any additional comments and proposals will be appreciated. Best regards, Oleg Nenashev -- 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 mailto:jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Discussion: Refactoring of JENKINS project in JIRA
On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev o.v.nenas...@gmail.com wrote: Any additional comments and proposals will be appreciated. I would not make an exception to the rule that “only a single component per GitHub repository should exist. stapler, winsw, are fine insofar as these are just repositories outside @jenkinsci; of course core needs to integrate new releases of these components to pick up fixes, but that generally does not need its own issue. (Note that some of these repos have their own GH issue trackers.) I would suggest that the JIRA component name exactly match the repository name in all cases, specifically meaning that we should use git-plugin rather than git, etc. (Originally I was thinking that the plugin artifactId/shortName should match the component, but using the repository name makes it clearer what is a plugin vs. some other library, and gives us better consistency overall.) hudson.sfbay is presumably obsolete, seeing as this Sun Microsystems intranet domain no longer exists. :-) Regarding native-rpm etc., I would leave these in core for the time being (with an appropriate label), but it would be great to see these be split into their own repositories with their own lifecycles. (This would also be a boon to anyone making an OEM distribution of Jenkins, as CloudBees does, since you would expect the native packaging to just take any Jenkins WAR file as an input.) -- 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. For more options, visit https://groups.google.com/d/optout.
