Document how to test - #171
Conversation
There was a problem hiding this comment.
This is nothing we've ever used thus I wouldn't feel comfortable including it in our readme.
There was a problem hiding this comment.
There was a problem hiding this comment.
I personally use chruby and ruby-install. There are many options, though -- rvm is still a widely used option as is rbenv/ruby-build.
Overall, we're agnostic to what kinds of tools contributors use (and I imagine not everyone on the RSpec core team uses chruby/ruby-install like I do), but like @JonRowe said I don't feel comfortable having a recommendation in the README that none of us core devs have used.
|
Is there anything salvageable from this PR? caveats about the difference in what travis does, and how this may fail your build? e.g. rubocop |
I think it's quite useful to include more documentation about how to contribute to RSpec but I'm not sure this is the best place for it (besides the encoding-specific stuff this gem deals with). What do you think about adding more to http://rspec.info/contributing/ ? If you want to contribute to that, the repo is https://github.com/rspec/rspec.github.io. |
|
Ok. Just trying to lower the burden for others as developing has been different from other gems |
Thanks, we do appreciate it! We just want to make sure that the contributing recommendations are things that core RSpec developers actually use and recommend. Also, since you've been working in the quagmire of encodings, I think your experience is pretty atypical: encoding issues have their own, unique set of problems that most contributors don't face. |
|
I will mention that |
|
@JonRowe you mean just I'm not a maintainer, but it bothers me that there's not more dev/ci parity in how you run your tests. At the very least, I think it should say that since CI will test 1.8.7, 1.9.2, 1.9.3, and 2.x, 'you may want to test on those as well if you think your changes may behave differently on the different versions.' And also to run 'rubocop lib' on MRI Ruby 1.9.3 or higher. That said, I do agree that it's also a priority to lower the barrier to PR, so I'm happy to change this to whatever minimal test-running-code you'd recommend. |
Ah support must be an odd one out, the other projects do run cucumber and rubocop as part of the default task. |
This is really intended to be Travis specific and does a lot more work than we would expect for short feedback (like checking across repos, and individual spec files)
The point of CI is both to lower the barrier of entry and ensure compatibility without running it, people will quickly see if they do something that breaks an older version of Ruby, however if you'd like to add a paragraph explaining they should check Travis for those failures please do.
|
|
@JonRowe Fantastic, thanks! (Sorry if I'm being annoying. I like docs :). |
There was a problem hiding this comment.
I didn't see that a place for this yet exists on http://rspec.info/contributing/. If something like this text is ok, I would make a PR to add it to the page and link to it from here.
|
I'd actually rather this went into the contributing page, and we added a note onto our read mes about checking there. Seems easier than having to repeat this across all 4/5 repos... |
|
I'll make the PR to the contributing page, and hopefully it will look pretty. Should I include the encoding caveats? (minus the reference to the vagrant box) |
|
You could include caveats about encoding although I think I'd like it reworded to be a bit more general. |
|
Ok, I think I'm just going to open a PR for discussion since I foresee some back and forth about where it should be on the site, how to format it, and wording |
|
rspec/rspec.github.io#65 if ok would direct me to add the docs to rspec-dev. |
|
Can we close this pull request? It looks like it's not in a state to merge and has been superseeded. |
|
Yeah |
4 participants
Related to work on #134 and #151