<dkubb>
I'm not going to waste precious oss time trying to placate people who make inflammatory statements like that
<mbj>
I read it like this. But I'm NOT a native english speaker.
<mbj>
"I have been publicly recommending (for example, on the Ruby Rogues podcast) that people use gems such as adamantium, descendants_tracker, and equalizer. However, if you only support use-cases that are directly needed by ROM, ignoring the broader community, I probably won’t continue recommending t"
<dkubb>
it's debatable that it's what he meant
<mbj>
For me the discussion left the tech level at this point.
<mbj>
I'll not infect all our gems with 18 code again.
<dkubb>
the main reason I don't care about 1.8 support is that I have no valid use cases for it, and I don't have enough time to fix 1.8 specific issues
<mbj>
It took us lots of time squeeze out backports.
<mbj>
Even if a person is volunteering to add 18 back I think it has an overall negative impact on the project.
<mbj>
We simply dont have enough time to target "anther plantform".
<mbj>
And adding 1.8 back in mainline will result in problems elsewhere.
<dkubb>
with your recommendation for a 1.8 specific set of gems was to have things like require 'equalizer/ruby18' ?
<mbj>
So only as a $libname/ruby18compat.rb I'd accept it the tree. And it would have to be require explicitly by users.
snusnu has quit [Quit: Leaving.]
<mbj>
Yeah he could maintain an libname/ruby18compat.rb, ideall in his tree.
<mbj>
Maybe I'm just having a bad day and bad emotions ;)
<lgierth>
good night
<mbj>
lgierth: cu
<lgierth>
i'll look into the heisen mutant further tomorrow
<mbj>
lgierth: keep me in touch
lgierth has quit [Quit: Ex-Chat]
<dkubb>
mbj: I'm not saying I'm 100% for 1.8.7 support, but if it was ever added, someone would have to actively fix the code when it broke under 1.8; which invididual authors would not be required to do.. whoemever volunteered to support 1.8 would be responsible for this
<mbj>
dkubb: And we should fix it in a way the normal code is not touched.
<dkubb>
mbj: I would not support it if it means constant friction and bitching all the time because that just sucks away my interest in oss
<mbj>
dkubb: Hence my idea to fix these places via a monkey patch.
<mbj>
dkubb: That would not trigger under 1.9 and needs to be required by users explicitly.
<mbj>
dkubb: Maybe also an out of tree gem. adamantium18 equalizer18
<dkubb>
yeah, that's actually not so bad
<dkubb>
you could have a 1.8 branch that someone is responsible for keeping in sync with master, except making it 1.8 compatible
<mbj>
yeah
<dkubb>
so it would lag behind master a bit at times, and someone else would be responsible for backporting stuff
<dkubb>
I actually created a devtools branch in memoizable that kind of goes the other way
<mbj>
heh
<dkubb>
it uses devtools and 1.9 specific syntax
<dkubb>
what I was doing is using it to identify problems with the code, and mutations.. which I'd fix, and then cherry-pick into master
<mbj>
dkubb: BTW I added the mutator config object to mutant. Need to connect it to CLI but the basic semantic works already.
<dkubb>
equalizer18, etc might not be so bad
<mbj>
Yeah it just removes all overhead in the main repos/branch.
<dkubb>
I really wish rubygems itself had a solution for this
<mbj>
Yeah rubygems and the ruby stdlib, the biggest problems holding ruby back.
<mbj>
Really happy to see more action towards rubygems bundler integration or the rewrite the rubinius guys are planning.
<mbj>
Also the stdlib move of rubinius was great.
snusnu has joined #rom-rb
<dkubb>
yeah both big things that we've wanted for a while
<mbj>
I think sooner or later jruby could use them also, dont really understood the problems the jruby community had with this move.
<dkubb>
I believe headius was talking about using it too
<dkubb>
it might require some work for each gem though. my guess is that things aren't arranged in quite the same way so there'll be some work to move things into each individual repo
<mbj>
Heh and the day bundle exec does NOT start a dependency resolution anymore and just trusts Gemfile.lock ;)
<mbj>
- I'll be super happy.
<dkubb>
what would be awesome is if each gem eventually included pure ruby, C and java implementations and it would just use the optimal case depending on the ruby impl
<dkubb>
if we can get mutation testing into the equation, people can beef up the specs for the pure ruby version, and then use those same specs to ensure the C and java versions are correct
<mbj>
dkubb: yeah
<mbj>
dkubb: Thats a really good point.
<dkubb>
I would love to see mutation testing used more in with ruby-spec
<dkubb>
it would probably require some mspec integration in mutant
<mbj>
dkubb: mspec is IMHO more well desigend than rspec for integration with a tool like mutant.
<dkubb>
I suspect it's simpler since it was designed more for rubyspec
<dkubb>
mbj: lemme think a bit more on the 1.8 issue, and I'll comment in github
<dkubb>
mbj: however, I am really tired of people trying to change people's minds by using ultimatums. I'm basically going to ignore them in the future, and will tell people why
<mbj>
dkubb: Yeah. I'll not veto a good solution. But it should ideally not produce any friction in our process.
<mbj>
dkubb: Lets just write down a ROM-INVARIANTS.txt doc.
<mbj>
dkubb: We'll not support X, because $Foo.
<dkubb>
mbj: I think in this specific case he wanted to know the supporting libs would consider use cases besides ROM specific ones
<mbj>
dkubb: We are supporting all use cases on the platform 1.9 +
<mbj>
done.
<dkubb>
mbj: I do think if we do agree to it we need to explicitly decide a time when everyone agrees the 1.8 support is dropped
<mbj>
dkubb: We already did IMHO, here in ROM.
<dkubb>
yeah, I mean for things like equalizer18, if that's what we decide
<mbj>
ahh, this one.
<dkubb>
having it in a separate branch and separate gem would mean no friction for anyone
<mbj>
agreed.
<dkubb>
you'd just write stuff for 1.9, test it with devtools, and someone else would be responsible for backporting it
<mbj>
Same with devtools, there could be an 18 branch
<mbj>
It would be uneasy to release.
<dkubb>
with it being with separate gems, there would be no pressure for the maintainer to release them in sync
<mbj>
What if a gem specifies equalizer, '~> 0.6'
<dkubb>
hmm
<mbj>
How that gem would poull equalizer-18 ?
<dkubb>
I dunno actually :(
<mbj>
It should be the other way round, many gems should be able to provide equalizer ~> 0.6 ;)
<mbj>
You provide a public interface.
<mbj>
Next problem, if we ship as a monkey patch, what if there is 1.9 in "main" code that has to be loaded first?
<dkubb>
I have seem some gems that provide a "java" version and somehow rubygems selects them under jruby. I wonder if the mechanism that does this is available so you could define an mri-18 version
<mbj>
Also not an option.
<mbj>
good question.
<dkubb>
it very well could exist and just not be well known
<dkubb>
and if it doesn't exist, we also could check to see if it would be an accepted patch
<mbj>
?
<mbj>
A patch to rubygems?
<dkubb>
yeah
<dkubb>
if rubygems is merging bundler maybe it'll allow platform specific deps