Jira (MCO-161) Investigate possible loss of parity between standard Puppet Labs packaging and "mco plugin package"

[R.I.Pienaar (JIRA)]

Title: Message Title

R.I.Pienaar commented on an issue   Re: Investigate possible loss of parity between standard Puppet Labs packaging and "mco plugin package" Users who wants to write their own plugins and download some others from the internet - either from other users or puppetlabs - really want to have parity in the whole eco system. They should know a package for a given plugin is built using the same methods regardless of origin. They want to use the same deployment method like a puppet defined type and they want to know that they can use this process with a plugin from any source. They want to know that the versions, licensing information, choices of what files go into what packages, dependency information etc is from the same source and used in the same way. They want to know that updating this meta data in one place will result in all the output artifacts being updated. These artifacts include packages, docs, rpcutil#inventory and more - all served from a single bit of metadata. Today this is done with mco plugin package, it reads the DDL file for author information, versions, licence and more and produce packages. For a user there is no additional effort needed above writing a plugin. They cannot use a plugin without a valid DDL and as soon as a plugin have a valid DDL its packagable, documented and so forth. Going from basic working plugin to releasable artifact is at most 1 command and no duplication of information and manual syncing etc. It does not dictate what SCM they use and does not dictate how they tag or release or whatever workflow they wish to use. Puppet Labs packages are up till recently built using the same tooling and so users can have great confidence that the plugin eco system as a whole is a single known state. If the build method is changing at Puppet Labs we cannot have confidence that the plugins supplied via puppetlabs.com is going to behave the same was the ones we create in-house and so we will be forced to rebuild puppetlabs plugins before we can use them with the same level of confidence next to our own. Add Comment   MCollective / MCO-161 Investigate possible loss of parity between standard Puppet Labs packaging and "mco plugin package" User feedback has brought up the fact that if plugin packaging moves to the standard Puppet Labs packaging methods "mco plugin package" becomes devalued. We need to have the discussion here if we should review moving forward with standardising packaging or move back to using "mco plugin package". This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.