> GH repo name
It's not like those aren't a mess. Just search the jenkinsci org for
'-plugin-plugin'. Those redundant '-plugin' suffixes should be donated to the
plugin repos without any -plugin suffix, like signal-killer,
seleniumhtmlreport, testabilityexplorer, cluster-stats -- and I didn't even
look for them! They also suffer from the same discoverability problem as short
names.
Then there are the many, _many_ plugins that haven't been forked into
jenkinsci, aren't on GitHub, or don't have public sources at all. I've brought
that up a while ago, and it affects >10% of plugins.
> ${shortName}-plugin
If the short names weren't so bad (~175 plugins with the -plugin suffix,
plugins getting renamed, major differences between short names and long names
making them undiscoverable, unreadable short names, or short names starting
with 'jenkins'), then this would work. As it is, it's just going to be horrible.
> write automations that work with JIRA without an extra level of
> indirection to look up the JIRA component name
If it's automated anyway, it'll be basically free to add a lookup via e.g.
component description or wiki plugin info (modulo the wiki being slow, but we
solved that with a cache before IIRC).
Which is great, because I have serious doubts we'll ever reach full consistency
between component names and anything else for all plugins, so it's going to be
needed anyway unless we're satisfied with automation working for 95% of plugins.
> Ubuntu, for example, uses dpkg names in its tracker
Because they're showing them to users all the time! Ubuntu package names are
shown by:
- the desktop edition's (14.04) setup (e.g. "Completely removed
language-pack-zh-hans-base (amd64)", and that's without showing the detailed
log)
- software descriptions ("Version" field) and 'History' tab in Software Center
- the server edition's (12.04) setup (below the progress bar, e.g. "Unpacking
libapt-pkg4.12...")
- the CLI package manager (and the default server install doesn't have a GUI)
I don't use Ubuntu so I've probably missed _a lot_ of places where package
names are really user visible.
In comparison, despite the more technical audience (compared to Ubuntu desktop
at least, IMO) Jenkins plugin short names are shown by:
- the deletion confirmation dialog (probably a bug)
- the file system, where users generally are not expected to change things
- depending on plugins, the occasional URL linked from somewhere
- the plugin info card on the wiki (and that's not part of the software itself)
- ...?
So it's not like Ubuntu uses those for the issue tracker while not showing them
to users at all.
> does not encourage you to file new bugs
> directly in its tracker; it offers a tool for generating a bug report,
> which includes searching for duplicates, picking the right internal
> component, and gathering diagnostics.
A tool would allow us to use whatever internal names we'd like to use for
components while having users file issues correctly, true. But we don't have
it. What we have are users filing issues against the wrong components because
it's too cumbersome to find the right one. So we should enable users to file
issues correctly, especially since the vast majority of developers are likely
to only watch their own components (if that), and the likeliness reports
getting ignored because they're filed against the wrong component is quite high.
Or we restrict issue filing to people who've first brought up any issues on the
mailing list (like Gradle does IIRC). That would also be possible, but a much
more radical change, and one that probably requires much more work upfront from
developers.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
