Pull from upstream

[blowmage]

Upstream has additional capabilities such as support for the Shoulda DSL.

[phlipper]

@blowmage, upstream also has this mess, which there is absolutely no interest in.

Given that this is the canonical repository (according to rawongithub/minitest-rails-shoulda#3 and the fact that the gem is actually managed from this repo), it would be nice to see the pull requests issued against this repo, sans the Hoe commit.

It would also be great if @rawongithub would update his repo to note that bousquet/minitest-rails-shoulda is now the canonical repo to avoid merge situations like this.

Thanks all!

[blowmage]

You should read the commit message. It explains why that commit is needed. :)

[phlipper]

@blowmage, it's funny, I did read that commit message, and besides the fact that the commit is purely a backwards move (no new functionality, additional dependencies), I was struck by the attitude which permeates the commit message.

You don't describe any value provided, and you make the assumption that the team currently managing the release has an interest in shifting infrastructure just because someone on the internet assured us it was better, with no justification.

The fact is, the Bundler tasks are sufficiently adequate to manage the current release workflow. If you would like to make a clearer case for Hoe, or volunteer to take over the gem maintenance, we'd be happy to reconsider the inclusion of Hoe.

Thanks for the input!

[blowmage]

The benefits of managing gems with Hoe are well known. I wouldn't think I need to summarize a five year old argument in a commit message.

I actually had this gem written for a month before @bousquet released his version. My commits in upstream are basically a reimplementation of the code (and tests) that I had lying around. The switch to Hoe was made because that is what I was using before and I didn't feel like manually updating the gemspec during each step.

I don't personally use shoulda, but I know folks that do. I'd be more than happy to own and maintain it.

[phlipper]

@blowmage I must admit that I'm a bit surprised by your hard-headed insistence on this matter.

The benefits of managing gems with Hoe are well known. I wouldn't think I need to summarize a five year old argument in a commit message.

Wow. I have no doubts that Hoe met your needs "back in the day", but I will reiterate my statement above: The fact is, the Bundler tasks are sufficiently adequate to manage the current release workflow.

I actually had this gem written for a month before @bousquet released his version.

Big ups. Unfortunately, this wasn't available anywhere at the time we were on the lookout for it. @rawongithub had a version mostly ready for use, and it was taken over. Contributions are certainly more than welcomed.

The switch to Hoe was made because that is what I was using before and I didn't feel like manually updating the gemspec during each step.

This is a weak argument, especially since you are not the current maintainer. You shouldn't be fiddling with the .gemspec unless you are changing dependencies or cutting a release. Again, the overhead of adding a new dependency here for zero new functionality is unjustified in the current maintainers opinions.

I don't personally use shoulda, but I know folks that do. I'd be more than happy to own and maintain it.

We do use Shoulda, We are happy to maintain this gem, and we are happy to accept all reasonable contributions. The majority of your commits would be very useful additions. Your attempt to jam Hoe down our throats is not appreciated.

Please consider re-submitting your pull requests, sans Hoe, as those would benefit all users of the gem. A healthy and vibrant community with solid testing libraries is surely something we can all get behind, no?

Thanks for your time and input.

[blowmage]

Big ups.

Classy.

This is a weak argument, especially since you are not the current maintainer. You shouldn't be fiddling with the .gemspec unless you are changing dependencies or cutting a release.

Or you are adding new files to the gem. But let's not litigate that argument again.

Again, the overhead of adding a new dependency here for zero new functionality is unjustified in the current maintainers opinions.

That's fine. I was only giving my justification that you said was missing.

Your attempt to jam Hoe down our throats is not appreciated.

I think you are severely misconstruing my request. I simply asked that the accepted changes to upstream would be accepted here. This repo states that it is a fork of upstream, which is why it was submitted there. I'm 100% okay with you saying "No, we aren't interested in switching to Hoe". I'm 100% okay with you asking that I resubmit these changes here. But I am not jamming anything down your throat.

[phlipper]

@blowmage I, and all of the maintainers, apologize if we misconstrued your request.

We believe that it is (or should be, especially amongst community 'elders') well known etiquette that editing the .gemspec file, or making any release-or-infrastructure-related changes, should be the domain of the project maintainers. We're always willing to accept feedback on those practices, but asking us to merge an upstream pull request which mixed useful functionality with breaking changes to our release workflow was a tough pill to swallow.

We appreciate your opinions about Hoe and we should have been more clear that we were looking for the value-add for the project, not for your personal workflow.

I, and we all, greatly appreciate that you took the suggestion to resubmit these changes without the Hoe commit. This will definitely benefit us all.

Thanks again for your passion and commitment to the MiniTest ecosystem.

[blowmage]

Hugs all around :heart: :kissing_face: :neckbeard: :heart: :two_men_holding_hands: :heart: