Date   
Puppet 4.9 probably the last 4.x

Thomas Mueller <thomas@...>
 

Hi all

Just stumbled upon this:

"The probably last version in the 4.x series is just about to be released (Puppet 4.9.0)."

https://tickets.puppetlabs.com/browse/PUP-1526?focusedCommentId=401969&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-401969


- Thomas

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Thomas Mueller <thomas@...>
 

Am 20.01.2017 um 11:43 schrieb Julien Pivotto:
On 20 Jan 11:17, Thomas Mueller wrote:

Am 20.01.2017 um 11:09 schrieb Julien Pivotto:
On 20 Jan 11:06, Thomas Mueller wrote:
OK, I accept that there will be no 1.0.0.

What i've planned to be 1.0.0 shall be 0.9.0.

Still there are **MAJOR** changes available in PR's which IMHO should
all be in 1.0.0. Please step in and comment ASAP to not waste time of
the author if the majority won't accept it.
1.0.0 makes sense if you plan to support that API for a longer time. E.g
release 1.1, 1.2 before releasing 2.0.0.

I do not know now if there would be future releases or not. I only
suspect there are many P3 users out there using this module
(jfrmyan/selinux: >4mio downloads) and that there is the possibility
that there might be release needed when some users come up with bugfixes
they use at their site.

But then there is the policy of VP that modules now are Puppet4 only. it
would be against that. I personally also like to be Puppet4 only as it
makes all easier.

there are so many pro/cons on this topic. I think we can discuss for
days - loosing time we could invest in making our modules better. :-)
VP policy is simple:

- No Puppet 3 releases
- Puppet 3 working code pushed to a puppet3 branch. We accept PR on that
branch.
so then 0.9.0 can be skipped entirely and the bugfixes for p3 should not
have happend in master.

Lets then focus getting to 1.0.0 !

- Thomas

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Julien Pivotto
 

On 20 Jan 11:17, Thomas Mueller wrote:


Am 20.01.2017 um 11:09 schrieb Julien Pivotto:
On 20 Jan 11:06, Thomas Mueller wrote:
OK, I accept that there will be no 1.0.0.

What i've planned to be 1.0.0 shall be 0.9.0.

Still there are **MAJOR** changes available in PR's which IMHO should
all be in 1.0.0. Please step in and comment ASAP to not waste time of
the author if the majority won't accept it.
1.0.0 makes sense if you plan to support that API for a longer time. E.g
release 1.1, 1.2 before releasing 2.0.0.

I do not know now if there would be future releases or not. I only
suspect there are many P3 users out there using this module
(jfrmyan/selinux: >4mio downloads) and that there is the possibility
that there might be release needed when some users come up with bugfixes
they use at their site.

But then there is the policy of VP that modules now are Puppet4 only. it
would be against that. I personally also like to be Puppet4 only as it
makes all easier.

there are so many pro/cons on this topic. I think we can discuss for
days - loosing time we could invest in making our modules better. :-)
VP policy is simple:

- No Puppet 3 releases
- Puppet 3 working code pushed to a puppet3 branch. We accept PR on that
branch.


--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Thomas Mueller <thomas@...>
 

Am 20.01.2017 um 11:09 schrieb Julien Pivotto:
On 20 Jan 11:06, Thomas Mueller wrote:
OK, I accept that there will be no 1.0.0.

What i've planned to be 1.0.0 shall be 0.9.0.

Still there are **MAJOR** changes available in PR's which IMHO should
all be in 1.0.0. Please step in and comment ASAP to not waste time of
the author if the majority won't accept it.
1.0.0 makes sense if you plan to support that API for a longer time. E.g
release 1.1, 1.2 before releasing 2.0.0.

I do not know now if there would be future releases or not. I only
suspect there are many P3 users out there using this module
(jfrmyan/selinux: >4mio downloads) and that there is the possibility
that there might be release needed when some users come up with bugfixes
they use at their site.

But then there is the policy of VP that modules now are Puppet4 only. it
would be against that. I personally also like to be Puppet4 only as it
makes all easier.

there are so many pro/cons on this topic. I think we can discuss for
days - loosing time we could invest in making our modules better. :-)

- Thomas

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Julien Pivotto
 

On 20 Jan 11:06, Thomas Mueller wrote:
OK, I accept that there will be no 1.0.0.

What i've planned to be 1.0.0 shall be 0.9.0.

Still there are **MAJOR** changes available in PR's which IMHO should
all be in 1.0.0. Please step in and comment ASAP to not waste time of
the author if the majority won't accept it.

1.0.0 makes sense if you plan to support that API for a longer time. E.g
release 1.1, 1.2 before releasing 2.0.0.


--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Thomas Mueller <thomas@...>
 

Am 20.01.2017 um 10:47 schrieb Julien Pivotto:
On 20 Jan 09:45, Rob Nelson wrote:
I think those poll options are misleading. I vote to use semver, and do the
breaking change now in 0.9.0 and drop puppet 3 support, then release 1.0.0
when the API is stable.
--
Rob Nelson
+1.

Use semver is mandatory.

But breaking changes are accepted in Semver for 0.x releases.

It makes no sense to release a 1.x if we plan to release a 2.x already.
OK, I accept that there will be no 1.0.0.

What i've planned to be 1.0.0 shall be 0.9.0.

Still there are **MAJOR** changes available in PR's which IMHO should
all be in 1.0.0. Please step in and comment ASAP to not waste time of
the author if the majority won't accept it.

- Thomas

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Julien Pivotto
 

On 20 Jan 09:45, Rob Nelson wrote:
I think those poll options are misleading. I vote to use semver, and do the
breaking change now in 0.9.0 and drop puppet 3 support, then release 1.0.0
when the API is stable.
--
Rob Nelson
+1.

Use semver is mandatory.

But breaking changes are accepted in Semver for 0.x releases.

It makes no sense to release a 1.x if we plan to release a 2.x already.

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Rob Nelson
 

I think those poll options are misleading. I vote to use semver, and do the breaking change now in 0.9.0 and drop puppet 3 support, then release 1.0.0 when the API is stable.
--
Rob Nelson

Re: puppet-selinux: Discussion about 1.0.0 and 2.0.0

Thomas Mueller <thomas@...>
 

There is a discussion on the version numbering. Which IMHO boils down
to: do we use SemVer with puppet-selinux or not.

I've created a poll to see what voxpupuli likes to do:

* yes = try to use SemVer, release a 1.0.0 before introducing many
breaking changes as 2.0.0
* no = release a 0.9.0 and do all the breaking changes with 1.0.0

Poll: http://doodle.com/poll/uxc4g3uwzxn9hm52

Discussion: https://github.com/voxpupuli/puppet-selinux/issues/184

- Thomas

Am 17.01.2017 um 20:26 schrieb Thomas Mueller:

Hi

Interested parties are invited to discuss how to proceed in sense of
version number with puppet-selinux:



- Thomas

puppet-selinux: Discussion about 1.0.0 and 2.0.0

Thomas Mueller <thomas@...>
 

Hi

Interested parties are invited to discuss how to proceed in sense of
version number with puppet-selinux:

https://github.com/voxpupuli/puppet-selinux/issues/184

- Thomas

Re: Howto: puppet strings

Thomas Mueller <thomas@...>
 

Am 13.01.2017 um 17:37 schrieb Tim Meusel:

On 13.01.2017 16:35, @dhollinger wrote:
There also puppet-strings docs for puppet-autofs:

https://voxpupuli.org/puppet-autofs ( https://voxpupuli.org/puppet-autofs )

Should we maybe add a page to voxpupuli.org with links to puppet-strings pages as they get published?
I think we should link them prominently in the modules README.md so
people find it on Puppet Forge and when visiting the Github repo. I
don't think there are much people going to voxpupuli.org to view module
documentation - I suspect nearly everybody surfs Github or Forge for
module informations.

- Thomas

PS: and the "Get in touch" information should be everywhere too. ;-)

Re: Howto: puppet strings

 

On 13.01.2017 16:35, @dhollinger wrote:
There also puppet-strings docs for puppet-autofs:

https://voxpupuli.org/puppet-autofs ( https://voxpupuli.org/puppet-autofs )

Should we maybe add a page to voxpupuli.org with links to puppet-strings pages as they get published?
yep, I already mentioned this in the IRC channel. Should we list all
modules with strings documentation at https://voxpupuli.org/docs/ ?

Re: Howto: puppet strings

David Hollinger
 

There also puppet-strings docs for puppet-autofs:

https://voxpupuli.org/puppet-autofs

Should we maybe add a page to voxpupuli.org with links to puppet-strings pages as they get published?

Howto: puppet strings

Thomas Mueller <thomas@...>
 

hi

we've just published the first module with puppet-strings docs on
voxpupuli.org [3]:

https://voxpupuli.org/puppet-selinux/

There is a good example at [1] how to document your puppet
class/defined type.

Then you only have to run `bundle exec rake strings:generate` to
actually generate the documentation to docs/ (you need also the PR [2]
to be modulesync'ed or you need to change it yourself).

Github Pages then can serve the master branch docs/ folder on
https://voxpupuli.org/$repo/ . It has to be enabled on each repo.


- Thomas

[1] Upstream puppet-strings:
https://github.com/puppetlabs/puppet-strings

[2] Modulesync PR for Puppet strings:
https://github.com/voxpupuli/modulesync_config/pull/304

[3] https://github.com/voxpupuli/puppet-selinux/pull/172

Re: Providing a Paste Service for Vox Pupuli

Rob Nelson
 

I think gists appear to be sufficient for our needs and reduces the likelihood of having to move content later, which is always a dicey proposition - data always gets lost, no matter the planning we do. All our repos are there already and it's not going to go away if people change jobs.

Are there technical limitations that we are encountering with gists? I think we should start with any specific problems and limitations and work to find solutions to them, and then if we determine self hosted services are the only reasonable solution we can investigate it from that point of view.

On Thu, Jan 12, 2017 at 8:53 PM Spencer Krum <nibz@...> wrote:


> I'm using it on my own since a few years, fraq and I can maintain it and

> my company can sponsor the webspace/vserver. We're already using my

> private filebin for the images that our IRC bot serves.



Fraq and Bastel running it seems fine to me.



> We can also

> continue with this one and move the stuff later to something else.



I doubt that we would ever move it. If we think there is a better thing

to do, lets start there.



> in my opinion: It just works, the API works, the we UI and

> the CLI tools.



All of this is true of github gist.



 > Also personally I prefer self hosted solutions because I

> don't trust cloud stuff.



We have everything else on github right now. We encrypt our deploy keys

to travis.  We trust service providers to do things more important than

this. I don't think "I don't trust cloud stuff" holds up considering we

have so many existing dependencies.





--

  Spencer Krum

  nibz@...







--
Rob Nelson

Re: Providing a Paste Service for Vox Pupuli

 

I'm using it on my own since a few years, fraq and I can maintain it and
my company can sponsor the webspace/vserver. We're already using my
private filebin for the images that our IRC bot serves.
Fraq and Bastel running it seems fine to me.

We can also
continue with this one and move the stuff later to something else.
I doubt that we would ever move it. If we think there is a better thing
to do, lets start there.

in my opinion: It just works, the API works, the we UI and
the CLI tools.
All of this is true of github gist.

> Also personally I prefer self hosted solutions because I
don't trust cloud stuff.
We have everything else on github right now. We encrypt our deploy keys
to travis. We trust service providers to do things more important than
this. I don't think "I don't trust cloud stuff" holds up considering we
have so many existing dependencies.


--
Spencer Krum
@nibalizer

Re: Providing a Paste Service for Vox Pupuli

Igor Galić
 

one allows nice rendering of markdown and html. If we ever need it we
can also host other stuff there, like pdf or video recordings from talks
we did.
What features do we need that the gist service on github does not have
right now?
They only support text, html and markdown content type/rendering.
i suggest we cross this bridge when it's burning beneath us.
and then we can use services such as archive.org

Especially considering this involves logins and user accounts, seems
high cost.
we can always give our hosting money as donations to archive.org…

o/~ i

Re: Providing a Paste Service for Vox Pupuli

 

Hi,


On 12.01.2017 20:44, Thomas Mueller wrote:

Am 12.01.2017 um 19:45 schrieb Spencer Krum:

I talked to fraq on IRC about adjustments and new features for our IRC
bot [0]. We came to the part where a paste service that is available
via an API might be needed. I would like to host the filebin [1]
application for us. It has a working webinterface + API + docs [2]. We
could host it as paste.voxpupuli.org and the IRC bot can report to it.
It would also be possible to give access to users if they would like to
(you can't post without an account). Besides other paste services this
one allows nice rendering of markdown and html. If we ever need it we
can also host other stuff there, like pdf or video recordings from talks
we did.
What features do we need that the gist service on github does not have
right now?
They only support text, html and markdown content type/rendering.
Especially considering this involves logins and user accounts, seems
high cost.

I also would like to understand what an existing service like gist
doesnt provide.

what do you want to save into this service?

who is maintaining the service like doing upgrades, verifying it still
works afterwards, fixing a service interruption? Who is maintaining the
useraccounts? Who has the filebin application knowhow? Whats the
bus-factor of this service?
I'm using it on my own since a few years, fraq and I can maintain it and
my company can sponsor the webspace/vserver. We're already using my
private filebin for the images that our IRC bot serves. We can also
continue with this one and move the stuff later to something else.
bus-factor in my opinion: It just works, the API works, the we UI and
the CLI tools. Also personally I prefer self hosted solutions because I
don't trust cloud stuff.


- Thomas



Re: Providing a Paste Service for Vox Pupuli

Thomas Mueller <thomas@...>
 

Am 12.01.2017 um 19:45 schrieb Spencer Krum:


I talked to fraq on IRC about adjustments and new features for our IRC
bot [0]. We came to the part where a paste service that is available
via an API might be needed. I would like to host the filebin [1]
application for us. It has a working webinterface + API + docs [2]. We
could host it as paste.voxpupuli.org and the IRC bot can report to it.
It would also be possible to give access to users if they would like to
(you can't post without an account). Besides other paste services this
one allows nice rendering of markdown and html. If we ever need it we
can also host other stuff there, like pdf or video recordings from talks
we did.
What features do we need that the gist service on github does not have
right now?
Especially considering this involves logins and user accounts, seems
high cost.

I also would like to understand what an existing service like gist
doesnt provide.

what do you want to save into this service?

who is maintaining the service like doing upgrades, verifying it still
works afterwards, fixing a service interruption? Who is maintaining the
useraccounts? Who has the filebin application knowhow? Whats the
bus-factor of this service?

- Thomas

Re: Providing a Paste Service for Vox Pupuli

 

I talked to fraq on IRC about adjustments and new features for our IRC
bot [0]. We came to the part where a paste service that is available
via an API might be needed. I would like to host the filebin [1]
application for us. It has a working webinterface + API + docs [2]. We
could host it as paste.voxpupuli.org and the IRC bot can report to it.
It would also be possible to give access to users if they would like to
(you can't post without an account). Besides other paste services this
one allows nice rendering of markdown and html. If we ever need it we
can also host other stuff there, like pdf or video recordings from talks
we did.
What features do we need that the gist service on github does not have
right now?
Especially considering this involves logins and user accounts, seems
high cost.


--
Spencer Krum
@nibalizer