Discussion: Refactoring of JENKINS project in JIRA

[Oleg Nenashev]

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

[Jesse Glick]

On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev <o.v.ne...@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.)

[Oleg Nenashev]

> 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.

--
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-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Beck]

On 05.06.2014, at 21:22, Oleg Nenashev <o.v.ne...@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'.

[Daniel Beck]

I changed some things in the wiki:

https://wiki.jenkins-ci.org/pages/diffpages.action?pageId=72778066&originalId=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).

> --
> 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.

[Kohsuke Kawaguchi]

On 06/04/2014 01:05 PM, Jesse Glick wrote:
> On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev <o.v.ne...@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/

[Kohsuke Kawaguchi]

I think the "Untriaged" state part needs more explanation and attention,
because the intention behind this change is to encourage core&plugin
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.

> --
> 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-de...@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

[Oleg Nenashev]

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 написал:

> <mailto:jenkinsci-dev+unsub...@googlegroups.com>.

[Slide]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

[Daniel Beck]

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.

[Oleg Nenashev]

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-de...@googlegroups.com.

[Daniel Beck]

On 10.06.2014, at 07:09, Oleg Nenashev <o.v.ne...@gmail.com> wrote:

> https://github.com/jenkinsci/ant-plugin

Sorry about that. Confused it with the Maven build step that's part of core.

[Jesse Glick]

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)

[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

[Oleg Nenashev]

Summary from the previous Project meeting (thanks to Daniel Beck for the notification).

1. JIRA components (jglick, 18:18:39)
   1. https://wiki.jenkins-ci.org/display/JENKINS/2014+JIRA+Components+Refactoring (danielbeck, 18:19:33)
   2. ACTION: oleg-nenashev to report on status of JIRA component change (jglick, 18:22:31)
   3. ACTION: kohsuke to implement JIRA component change (jglick, 18:22:39)
   4. AGREED: want unsorted component empty, but maybe need a more descriptive name (jglick, 18:27:51)
   
   
2. JIRA components (jglick, 18:29:07)
   1. ACTION: oleg-nenashev to document intended usage of unsorted (jglick, 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 написал:

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

[Oleg Nenashev]

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

To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Tom Fennelly]

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.
• Here's the JIRA: https://issues.jenkins-ci.org/browse/INFRA-123

Possible text edits aside, I think this should help.

[Richard Mortimer]

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

[Stephen Connolly]

"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-users@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+unsubscribe@googlegroups.com.

[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.

[Oleg Nenashev]

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 написал: