On May 20, 2011 4:28pm, Pado <peak...@gmail.com
> There is only Merb C.T.(Community Team). Please join to new Merb C.T.
> and let' create the greatest Merb ng that the originalMerb had dreamed of!
Please do! If your stuff is good, I'll commit it :-)
Look at the active_support branch for a base. It works without Extlib (merb <=1.1 is the last thing that actually uses Ext), uses RSpec 2, and has some steps towards clean charset handling on Ruby >=1.9.2, but is otherwise mostly unchanged in terms of the API. I'll likely merge it back to master soon-ish. The 1.0 specs are already gone, and I don't see a reason to stick to the old API.
The usual channels are open, so there's no need to bootstrap a new project. I have full access to the Lighthouse tracker and Github repo, and I promise not to run away and leave stuff dangling. Seeing you on the IRC channel would also be great (#merb on Freenode).
Adopt a bug: https://merb.lighthouseapp.com/projects/7433-merb
Oh look, participation! https://github.com/merb
Michael D. Ivey" <michae...@gmail.com
> What problem does Merb solve, today, that isn't solved by Sinatra, Rails,
> or simple Rack handlers?
Is that really important? Some people don't like Rails (in fact, that was a major reason why Merb came into being) or other frameworks, some are just "anti-establishment" (rock on!), and some just want something to play with. With Merb in its current state, there's the opportunity to do major breaking changes that wouldn't be possible with – let's be blunt – frameworks with a significant userbase.
If we end up with three lines of code in a Rack handler doing everything that Merb did before, that's fine in my book.