dkubb changed the topic of #datamapper to: Datamapper v1.2.0 | Mailing List: http://is.gd/aa9D | Logs: http://is.gd/qWAL7V | DataMapper 2 Renamed to ROM, see #rom-rb for development
<tpitale>
I was very asleep when that came through :-)
<tpitale>
East coast time
<dkubb>
no worries. I don't keep IRC open often because it can sometimes be distracting when trying to work
<tpitale>
indeed
<dkubb>
it's surprising that you're still using DM. I am using it on one project I maintain that was started a while ago
<tpitale>
Same.
<tpitale>
Projects been around for 6 years
<tpitale>
It uses some core features of DM that just aren't easy in AR or much of anything else
<tpitale>
ROM isn't quite there yet
<tpitale>
There just isn't anything as good …
<dkubb>
yeah, I can't see us adding new features to DM but bug fixes would be accepted provided they come with specs that fail prior to the fix
<tpitale>
absolutely
<dkubb>
yeah, ORM dev takes so much time it's hard to get something off the ground
<tpitale>
True
<tpitale>
so much too it
<tpitale>
I'm hoping it just stays stable with updates to ruby/rails until I can switch to ROM
<tpitale>
I'm just happy with DM
<tpitale>
I think that's just bugfixes
<dkubb>
I rarely run into problems with DM like I do with AR, which is kind of funny
<tpitale>
right?
<tpitale>
yeah
<tpitale>
exactly
<dkubb>
yeah, I would lump fixes to keep it running on modern ruby's in with bug fixes too
<tpitale>
yeah, that's all I'm hoping for
<dkubb>
it could be that I know where all the sharp edges are
<tpitale>
true
<tpitale>
I think DM is feature complete as far as I use it
<tpitale>
I'm hoping we can get gem releases when those bugfixes happen
<dkubb>
one of the first things I would love to see is getting DM gems passing again on Travis CI. that way we can ensure new commits don't break the build
<tpitale>
absolutely
<dkubb>
I think the matrix we test against is a bit stale
<tpitale>
yeah
<tpitale>
pretty sure we can drop 1.8 support :-)
<dkubb>
I don't plan on supporting 1.8 or 1.9 since I think 1.9 is past EOL isn't it?
<tpitale>
1.9 is EOL too
<tpitale>
but I do know some folks still use it :-/
<tpitale>
but 1.8 should definitely go
<dkubb>
there may be people running DM with 1.9, but I think if you're stuck on 1.9 you've probably given up on being able to run the latest versions of gems
<tpitale>
probably true
<tpitale>
if we're going to support newer rubies … that means people need to be updating
<tpitale>
so I think 1.9 could go too
<dkubb>
yeah, also jruby 1.8 and 1.9 support, plus the older rbx's
<tpitale>
yep
<tpitale>
Aside from re-architecting DM … what features did you feel like you never had time to add?
<tpitale>
Now that virtus is more stable, I might be able to work on what _solnic_ was doing using virtus for properties
<tpitale>
for like a low-ambition DM 2 :-)
<tpitale>
I use virtus a lot
<dkubb>
probably adding CHECK constraints that reflect on the validations
<dkubb>
I use CHECK constraints all the time on AR and DM projects, but I end up adding them manually
<dkubb>
the funny thing about the migrations API is that I would probably scrap most of it and just use pure DDL statements. it's what I do 90% of the time now
<tpitale>
So drop auto-upgrade/migrate features?
<dkubb>
but really, the first thing I would probably do is bring the build system inline with more "modern" approaches that @mbj and I have been using for newer gems
<tpitale>
like mutant?
<dkubb>
no, auto-upgrade and auto-migrate are good for quick testing
<tpitale>
okay
<dkubb>
yeah, mutant is a part of it, but I don't know if DM's specs would be a good fit
<dkubb>
they touch the db alot, which is slow in mutation testing
<dkubb>
I would probably use https://github.com/mbj/devtools and set the thresholds for the build system so it passes with the code in it's current state. at the very least this would ensure there aren't any regressions in future refactorings or PRs
<dkubb>
I did actually mutation test parts of DM way back
<dkubb>
also the release-1.2 patches I've added in the last 6 months were all mutation tested before being merged
<dkubb>
it was just done more manually rather than using rake tasks
<dkubb>
actually, that's not entirely true.. I recall a few changes in dm-rails that didn't get mutation tested, but that was because they were for a client and I couldn't justify mutation testing a relatively low risk piece of the code
<dkubb>
it's different for code that was built from the ground up with mutation testing in mind
<dkubb>
mbj and I maintain a whole rails project, with a spree engine, that is 99% mutation tested
<dkubb>
the last 1% is legacy code that we just haven't gotten to yet. we chip off a bit every few weeks
<tpitale>
impressive
<tpitale>
So, for your migration change, you're thinking of just making it easier to use DDL, rather than a ruby DSL?
<dkubb>
well, that's just something I would like to do given more time, but I don't know if I'll get to it
<dkubb>
I'm more talking about if I did a new DM today
<dkubb>
although I don't know if I'd go with an Active Record style ORM
<tpitale>
Yeah, I'm thinking I'll work to get the build matrix updated and passing
<tpitale>
Keep the gems in decent shape for bug fixes
<tpitale>
try to clean up issues/PRs
<tpitale>
Maintenance mode
<dkubb>
really, my main thing would be fixing the build system, then working on getting bug fixes in.
<tpitale>
roger that
<tpitale>
I don't want to get ahead of myself
<tpitale>
:-)
<dkubb>
yeah PRs that add features would probably be closed with a good explanation
<dkubb>
PRs with bug fixes would be rebased on top of the latest commits and checked to make sure they still apply. they would have to include failing specs
<tpitale>
yep
<dkubb>
all the open PRs we have are a bit overwhelming. I would probably start with dm-core and then work outwards
<tpitale>
I might dip my toe in with some smaller gems when getting travis passing … before stepping up to dm-core :-)
<tpitale>
But I'll keep that in mind
<dkubb>
heh
<tpitale>
I think I have access to all the repos
<tpitale>
should I still send you PRs?
<dkubb>
yeah, I would think we could use the same matrix everywhere.. so I might actually start by trimming down the matrix and adding the more modern stable ruby's to it
<dkubb>
yeah, sure
<tpitale>
maybe I'll tag the PRs with something specific to this endeavor
<tpitale>
so we can split those from the rest of the noise
<dkubb>
we generally don't want to merge into master directly. I would still PR most things and have someone else review and merge
<tpitale>
yep
<dkubb>
the only PRs that I might let slide into master would be low risk things, like say a README or other doc change
<tpitale>
So, you, _solnic_, maybe dbussink should always sign off?
<dkubb>
s/PRs/commits/
<tpitale>
Anyone else?
<dkubb>
mbj could too
<tpitale>
Cool
<dkubb>
I don't think he is going to be doing too much OSS
<tpitale>
Didn't know you two worked together
<tpitale>
that's fair
<dkubb>
yeah we do now
<dkubb>
solnic and I used to work together a few years ago
<tpitale>
I'm just hoping for some eyes … I'll try to keep it spread out
<tpitale>
Oh, I didn't know that either
<dkubb>
it was solnic, avdi and myself for a couple of years
<tpitale>
Oh
<tpitale>
there ya go
<tpitale>
Maybe I'll recruit some of my LS colleagues for this :-)
<dkubb>
then solnic left to work on his own company, and avdi moved onto doing rubytapas FT, then we brought mbj and snusnu onto the team
<tpitale>
I remember working on DM with someone at RailsConf in Portland in 2008 :-)
<tpitale>
working on has n, through:
<tpitale>
ha
<dkubb>
ahh yeah, nasty stuff
<tpitale>
ha
<dkubb>
I was never happy with m:m
<dkubb>
I really liked how all the collections have a uniform api, but m:m internals are gross
<tpitale>
gotcha
<tpitale>
I think the edge cases can be sharp sometimes
<dkubb>
not any one person's fault mind you, just a really hard problem to get right
<tpitale>
absolutely
<tpitale>
zero blame
<dkubb>
what's LS stand for? Living Social?
<tpitale>
Auto upgrade is actually one of the things that bites me sometimes
<tpitale>
Yeah
<dkubb>
ahh ok, I didn't know you guys used DM
<tpitale>
We don't as a company
<tpitale>
I just work there
<dkubb>
also I didn't know LS had been around for 6 years
<dkubb>
ahh ok
<tpitale>
Yeah, been around for awhile
<tpitale>
used to make facebook apps
<tpitale>
I've only been there for 3 years
<tpitale>
Chad Fowler times
<tpitale>
anyway, time for coffee for me
<tpitale>
this has been super-helpful
<tpitale>
I'll start with some of the build matrix stuff this week
<dkubb>
yeah, I've gotta get back to my family.. don't want to spend all Saturday on the computer. I typically do my non-work hacking at nights (PST)