My best understanding from the posting is that it's going to be a "stable" version of the "Haskell Platform" set of packages.
Haskell has been notorious for moving (too?) fast while not maintaining decent backwards/forwards compatibility, a problem made worse by some tooling issues ("cabal hell"). Now most of the technical issues should be solved.
It does seem to be a competitor. They could use the same infra to do the HP versioning and builds. Some NIH going on?
The key here seems to be the level of automation, which is great to see.
Unfortunately, I think it's a bit of a branding thing, too. To most people's eyes the HP is something of a failure since it's so slow to release—never mind the stabilizing effect it has had on all constituent projects. Stackage thus grabbed some market- and mind-share by promising a closer-to-bleeding-edge update path at the cost of lesser stability. From this position they're peeling back a little bit, trading off newness for a bit more stability, in what appears to be the easiest-to-maintain fashion.
So from that, it's sort of culturally incompatible with HP, unfortunately. It'd be very nice if some crosscutting could be had once-and-if LTS stabilizes as a product.
Actually, the ideas for LTS Haskell came out of conversations I had with Duncan and Mark at ICFP. The original idea was to create a GPS Haskell that would encompass a "best of both worlds." LTS Haskell is a first step towards that, and I'm hoping that Haskell Platform and Hackage ultimately fold this stuff back in.
Sounds good. I had assumed you were heading in this direction. The approach was something Duncan and I wanted to try in 2007/2008 but we didn't have resources at the time. Now the infrastructure is there, automatically identifying stable sets, tagging and releasing them is a good step. If you can get to the point of computing the next HP set in the same fashion, that will be a big win for stability.
The core set of packages (e.g. those in the platform) tend to not break backwards compatibility, but you're right that there are still packages that move fast and do.
Haskell has been notorious for moving (too?) fast while not maintaining decent backwards/forwards compatibility, a problem made worse by some tooling issues ("cabal hell"). Now most of the technical issues should be solved.