Removed up for adoption source code management plugins from wizard

[StefanSpieker]

In another PR I try to improve the JavaScript of the wizard and during testing I recognized that we are somehow recommending some not that active SCM plugins.

Removed up for adoption source code management plugins from wizard, which shows now this in source code management:

Links to plugins (with each the "up for adoption" headline):

• clearcase plugin
• cvs plugin
• repo plugin

Testing done

Ran the wizard with hpi:run and the property jenkins.install.runSetupWizard=true

Screenshots (UI changes only)

Before

After

Proposed changelog entries

Remove up for adoption Source Code Management plugins from wizard (clearcase, cvs and repo)

Proposed changelog category

/label removed

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[daniel-beck]

somehow recommending some not that active SCM plugins

Two of them were last released 3 months ago. Did you confirm the maintainers aren't maintaining? I've seen the labels used in the past to indicate that maintainers would like co-maintainers to help, but are otherwise doing OK.

[StefanSpieker]

Ok, I just thought that setting up a new instance and directly seeing up for adoption after the first startup is not the best experience. I haven't checked with the maintainers.

[mawinter69]

I would consider clearcase (0.6% installs) and repo (1.26% installs) as niche cases where is is questionable that they should be offered at all in the setup wizard. I could imagine that the real usage numbers are even lower because some people just installed everything.

[daniel-beck]

I would consider clearcase (0.6% installs) and repo (1.26% installs) as niche cases where is is questionable that they should be offered at all in the setup wizard. I could imagine that the real usage numbers are even lower because some people just installed everything.

The setup wizard was introduced in April 2016, and we have usage stats from long before then. There's a small bump, especially once there was a 2.x LTS, but it doesn't look that significant. We could agree that these plugins are simply not popular or relevant enough to keep in there (coupled with maintenance issues), but this explanation doesn't seem to hold up (May/June 2016 is where popularities cross).

I added these plugins originally to the setup wizard since they were SCMs, and those are central to Jenkins's functionality, relaxing some "popularity" rules for the category that applied otherwise. I'm OK with removing these plugins, but we should apply criteria consistently.

[timja]

I don't think we need to have these in the setup wizard, its unlikely new instances will need these.