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.
