> 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 <[email protected]>:
> On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev <[email protected]>
> 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
> [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
