Please give a look to this:
https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md
it's basically the output of the (somehow limited, but well thought over) 
discussion about naming standards on 
https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA

It has for sure many more parameters that the ones you can expect in a 
module, but the point is always that you use the ones you need.
It tries to define some naming patterns for parameter, for cases where they 
are needed or would be nice to have.

I really would prefer that a common and shared discussion on a single 
parameters list could be done not only for PuppetLabs modules but for any 
module that somehow wants to follow a standard naming convention.

What about commenting / committing alternative lists directly on GitHub ?
(The repo is now under a generic stdmod GitHub organization, it can be 
moved anywhere, eventually under PuppetLabs organization, and, once 
completed,  remain a reference for naming standards)




On Monday, July 8, 2013 6:02:25 PM UTC+2, Ashley Penney wrote:
>
> On Mon, Jul 8, 2013 at 11:12 AM, Alessandro Franceschi 
> <a...@lab42.it<javascript:>
> > wrote:
>
>>
>>
>> On Saturday, July 6, 2013 1:30:15 AM UTC+2, Nan Liu wrote:
>>
>>> On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney <ashley...@puppetlabs.com
>>> > wrote:
>>>
>>>> Now that Puppetlabs has a module team we thought we should start trying 
>>>> to keep the community informed as to what we're doing and why on earth 
>>>> we're doing it.  I wanted to put together a short update (I'm aiming to do 
>>>> these every friday) as to where we stand.
>>>>
>>>> This was our first week working full-time on Modules, and I spent a 
>>>> good chunk of time this week filling in paperwork, meeting people I've 
>>>> only 
>>>> seen on IRC, and trying to get up to speed with internal systems and 
>>>> tools. 
>>>>  This slowed us down a little.
>>>>
>>>
>>> Hi! I'm glad to hear this is prioritized.
>>>
>>> We focused specifically on puppetlabs-mysql and puppetlabs-apt this week 
>>>> to try and get the PR/issue count under control.  To give you an idea of 
>>>> the progress we've made:
>>>>
>>>  
>>>> puppetlabs-mysql: Closed/merged 20 PRs.
>>>> puppetlabs-apt: Closed/merged 18 PRs.
>>>>
>>>> We're going to continue iterating over different modules each week to 
>>>> deal with the enormous backlog of PRs and issues and keep bashing these 
>>>> into shape until we're caught up with all the community submissions.
>>>>
>>>> We appreciate each and every PR you send us (unless you forgot specs, 
>>>> which makes me shout at a puppy) and hopefully we'll be able to shorten 
>>>> the 
>>>> cycle of merging them as this work goes forward.
>>>>
>>>> As a result of this week's work we have released:
>>>>
>>>> http://forge.puppetlabs.com/**puppetlabs/apt/1.2.0<http://forge.puppetlabs.com/puppetlabs/apt/1.2.0>
>>>> http://forge.puppetlabs.com/**puppetlabs/mysql/0.8.0<http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0>
>>>>
>>>
>>> Would it be possible for the module team to review Alessandro's "The 
>>> handy grail of modules standards" thread and set a variable name standard 
>>> moving forward? It doesn't even need to be quite as comprehensive, but some 
>>> basic standard to start. We use quite a few modules as upstream, and would 
>>> love to see some consistency even if it means breaking changes. Thanks 
>>> again, and look forward to the great things coming out of the module team.
>>>
>>> Nan
>>>
>>
>> +1 of course.
>> We all say some naming standards are needed and we still continue to make 
>> our modules in our ways.
>> For the sanity of Puppet modules ecosystem let's do something about it.
>>
>
> This is definitely something we want to do and need to do.  I've been a 
> little hesitant to wade down into the whole "these are the specific 
> parameter names we want to use" and building out a huge set of guidelines, 
> but I do have a straightforward question for the list along these lines:
>
> We're refactoring the ntp module to try and be a little bit of a better 
> design rather than one giant class.  We've been having some discussions in 
> the PR about the right way to name the following options:
>
> manage_service
> ensure_package
> package_enable
>
> I was leaning towards:
>
> ensure_package
> enable_package
> ensure_service.
>
> But it's been proposed that:
>
> service_ensure
> package_enable
>
> Makes better sense in terms of being able to scan for things.
>
> Does anyone reading this have strong preferences either way?  Now is the 
> time for us to slowly start renaming parameters across the modules as we 
> work on bringing in PRs, so speak up now. :)
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to