Best Practices

[grubernaut]

Opening an issue for best practices for continued development of this gem.

Thoughts for discussion:

• Commits should not be merged directly into master. This prevents any form of discussion from taking place
• PR's should not be merged without proper rspec tests covering the change. (I'm just as guilty of this one)
• Propose to nominate @ytsarev as a second Collaborator. They have a thorough knowledge of this gem and the code involved.
• If @ytsarev accepts nomination of Collaborator, we should not merge any PR's unless there are at least two 👍's on the PR. More eyes will help us to hopefully never again push a broken version of this gem to RubyGems.

Thoughts, Concerns?

[neillturner]

Well if more people involved then this would be great.. !!!
But not merging commits directly to master I assume you mean I need to work on a fork or branch and merge like everyone else -)
I'm always happy to have more collaborators!!!!

[grubernaut]

Definitely could be nice to have another contributor, and one of the biggest benefits would be code review on pull requests. Preventing each other from merging in code that could have been written better, etc

[ytsarev]

@grubernaut @neillturner hi guys, thanks for your trust, I'm definitely willing to participate.

[grubernaut]

Are we all in agreement with these proposed guidelines?

If so, we should close this issue

[neillturner]

yes this would be good so lets close. I think most of the functionality is there now but new versions of puppet and operating systems will create a testing maintenance issue. so beffing up the spec and fixtures so we have an automated test suite would be very useful.
to test different operating systems we need servers with the different oses. The free teir at aws would give a micro server that we could run up with different oses. AWS has a good amount of OS images.
of vagrant and virtual box might be the way. There is a new version of virtual box. maybe its faster and better.

[ytsarev]

the e2e testing is an interesting topic. I have a positive experience with kitchen-docker, we can test several platforms within one instance, it's pretty efficient.

[looztra]

for the record, travisci and circleci allow customers to run docker
containers, that could be a good fit for such e2e automated testing

On Sat, 12 Sep 2015 at 13:28 Yury Tsarev notifications@github.com wrote:

the e2e testing is an interesting topic. I have a positive experience with
kitchen-docker, we can test several platforms within one instance, it's
pretty efficient.

—
Reply to this email directly or view it on GitHub
#72 (comment)
.