Puppet users - Jul 2013 - Fwd: [Module team] Much ado about modules

Hello!

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.

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/mysql/0.8.0

Thanks,

-- 
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+unsubscribe@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.

On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney
<ashley.penney@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/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

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

On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney
<ashley.penney@puppetlabs.com
> wrote:
> Hello!
>
> 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 is awesome I''ve been waiting for this to be prioritized as well.
:)

>
>
> 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.
>
>
>
Specs are really hard for first time contributors, a lot of Pull Requests
are still in the backlog of unmerged PRs due to the submitter being asked
to submit Spec tests. I would like to see some documentation we can point
first time contributors too. The corresponding ticket is:

https://projects.puppetlabs.com/issues/14456

Also perhaps the new module team can make the final decision on:

https://projects.puppetlabs.com/issues/11118

Looking forward I would like to see Puppet modules development remove the
bottleneck on Puppetlabs staff and other module maintainers to merge PRs.
Often times I submit PRs for new OS support or additional features to
really good modules on Github or the Forge and the maintainer does not have
the time or OS to review, test and merge the PR.

A possible solution might be to mirror The Openstack Project. They have a
pretty effective process of using Gerrit + Jenkins to review, test, and
merge code.

The goal would be to allow us to have "community supported" official
modules kind of like how the Nagios project has a nagios-plugins repo. I
think a system like this or similar would allow us to:

 * Submit new modules for inclusion as "official community" modules
 * Support faster iteration on more operating systems
 * Reduce the number of competing modules on the forge, everyone
doesn''t
need there own custom Apache module
 * Improve the quality of modules and increase the amount of testing
 * Reduce the number of "bad" modules on the Forge

I look forward to hearing people''s ideas and continuing the discussion.


William

-- 
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+unsubscribe@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.

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<javascript:>
> > 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/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.

-- 
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+unsubscribe@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.

On Mon, Jul 8, 2013 at 11:12 AM, Alessandro Franceschi <al@lab42.it>
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+unsubscribe@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.

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+unsubscribe@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.

Hello.  It would be nice if there was a way to browse all modules on Puppet 
Forge.  I can browse all the modules released by Puppet Labs @ 
http://forge.puppetlabs.com/puppetlabs, (same for any author for whom I 
know the username) but as far as I know, there is no way to browse all 
modules. (Perhaps there is with the Puppet Module Tool, but I can''t get
that to work through our proxy.)
 
Thanks.   

On Friday, July 5, 2013 2:05:44 PM UTC-4, Ashley Penney wrote:
> Hello!
> 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.
>  
> 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/mysql/0.8.0
>
> Thanks,
>
-- 
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+unsubscribe@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.

On Mon, Jul 8, 2013 at 10:55 AM, root <clri.c0t0d0@gmail.com> wrote:
> Hello.  It would be nice if there was a way to browse all modules on
> Puppet Forge.  I can browse all the modules released by Puppet Labs @
> http://forge.puppetlabs.com/puppetlabs, (same for any author for whom I
> know the username) but as far as I know, there is no way to browse all
> modules. (Perhaps there is with the Puppet Module Tool, but I
can''t get
> that to work through our proxy.)
>
http://forge.puppetlabs.com/modules

Nan

-- 
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+unsubscribe@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.

On Mon, Jul 8, 2013 at 9:02 AM, Ashley Penney <apenney@gmail.com> wrote:
> On Mon, Jul 8, 2013 at 11:12 AM, Alessandro Franceschi
<al@lab42.it>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
>
 I would agree with resource_attributes order instead of the other way
around. It also makes sense because you can just introspect the class
parameters with .sort and everything is in an easy to find order.

Thanks,

Nan

-- 
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+unsubscribe@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.

Ah, that workes nicely, thanks. 

On Monday, July 8, 2013 2:02:46 PM UTC-4, Nan Liu wrote:
> On Mon, Jul 8, 2013 at 10:55 AM, root <clri....@gmail.com
<javascript:>>wrote:
>  
> http://forge.puppetlabs.com/modules
>
>  
>
-- 
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+unsubscribe@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.

On 08.07.2013 20:06, Nan Liu wrote:
>     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
>
>
>   I would agree with resource_attributes order instead of the other way
> around. It also makes sense because you can just introspect the class
> parameters with .sort and everything is in an easy to find order.
Indeed, the grouping by lexical order is one of the main arguments for 
that. Also it mirrors the order in which the words are written in the 
manifest:

   class X { package { Y: ensure => present
     =>
   $X::[package_][Y_]ensure == present

Regards, David

-- 
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+unsubscribe@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.

Given that
https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md is
based on the same resource_argument pattern can we make a step further and
define names that can be used for any module and call them "suggested
standards"?
Restricting the discussion to PuppetLabs modules only is a wasted occasion.

I don''t want to be repetitive, but many people are saying that some
naming
standards are necessary and I personally think that the effort to define
them is not great, being just a matter of defining (well thought) names
that everybody can use.

my2c


On Tue, Jul 9, 2013 at 10:43 AM, David Schmitt <david@dasz.at> wrote:
> On 08.07.2013 20:06, Nan Liu wrote:
>
>>     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
>>
>>
>>   I would agree with resource_attributes order instead of the other way
>> around. It also makes sense because you can just introspect the class
>> parameters with .sort and everything is in an easy to find order.
>>
>
> Indeed, the grouping by lexical order is one of the main arguments for
> that. Also it mirrors the order in which the words are written in the
> manifest:
>
>   class X { package { Y: ensure => present
>     =>
>   $X::[package_][Y_]ensure == present
>
> Regards, David
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/**
>
topic/puppet-users/**ayYXxU3ft04/unsubscribe<https://groups.google.com/d/topic/puppet-users/ayYXxU3ft04/unsubscribe>
> .
> To unsubscribe from this group and all its topics, send an email to
>
puppet-users+unsubscribe@**googlegroups.com<puppet-users%2Bunsubscribe@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<http://groups.google.com/group/puppet-users>
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
>
>
-- 
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+unsubscribe@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.

On Monday, July 8, 2013 11:02:25 AM UTC-5, Ashley Penney
wrote:
>
>
> 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. :)
>

In an abstract sense, I think I prefer <component>_ensure over 
ensure_<component>, on the principle that the most-significant name 
component should come first.  It''s not really about scanning for things
for
me, but rather about grouping related things together.  That carries 
advantages for visual scanning, but the grouping aspect is more fundamental.

In a more concrete sense, if you are naming parameters of a class, then the 
datum we abstractly refer to as <component>_ensure might more sensibly be 
named something else in that context.  For example, in a class 
ntp::service, I would certainly choose the parameter name "ensure"
over
"service_ensure".  There is therefore some dependency on module
structure
and intended use.


John

-- 
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+unsubscribe@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.

On Tue, Jul 09, 2013 at 09:23:39AM -0700, jcbollinger
wrote:
> 
> 
> On Monday, July 8, 2013 11:02:25 AM UTC-5, Ashley Penney wrote:
> >
> >
> > 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. :)
> >
> 
> 
> In an abstract sense, I think I prefer <component>_ensure over 
> ensure_<component>, on the principle that the most-significant name 
> component should come first.  It''s not really about scanning for
things for
> me, but rather about grouping related things together.  That carries 
> advantages for visual scanning, but the grouping aspect is more
fundamental.
+1
> 
> In a more concrete sense, if you are naming parameters of a class, then the
> datum we abstractly refer to as <component>_ensure might more
sensibly be
> named something else in that context.  For example, in a class 
> ntp::service, I would certainly choose the parameter name
"ensure" over
> "service_ensure".  There is therefore some dependency on module
structure
> and intended use.
+1

NB: I can''t remember the last time I agreed with someone on everything
that
he says.

-- 
Nikola

-- 
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+unsubscribe@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.

On Tuesday, July 9, 2013 6:23:39 PM UTC+2, jcbollinger
wrote:
>
>
>
> On Monday, July 8, 2013 11:02:25 AM UTC-5, Ashley Penney wrote:
>>
>>
>> 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. :)
>>
>
>
> In an abstract sense, I think I prefer <component>_ensure over 
> ensure_<component>, on the principle that the most-significant name 
> component should come first.  It''s not really about scanning for
things for
> me, but rather about grouping related things together.  That carries 
> advantages for visual scanning, but the grouping aspect is more
fundamental.
>
> In a more concrete sense, if you are naming parameters of a class, then 
> the datum we abstractly refer to as <component>_ensure might more
sensibly
> be named something else in that context.  For example, in a class 
> ntp::service, I would certainly choose the parameter name
"ensure" over
> "service_ensure".  There is therefore some dependency on module
structure
> and intended use.
>
FYI, I''ve integrated this suggestion, and other de facto standards in:
https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md
 

-- 
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+unsubscribe@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.