Within the past week, I’ve started receiving patches for Mars via GitHub. As I simply want this codebase to go where it can attract the biggest development community, I see no reason not to go with the flow.
I initially forked Scott’s codebase, but via email he indicated that was not his intent, so I deleted my fork and pushed out a new master — including Scott’s work.
If people want to provide patches to Mars, I have GitHub invites I can offer.
Sam, dig into Git, hard. I picked up Bazaar after reading about your experiences with using it for Venus and loved it. Playing with Git over the past few months has been every bit as rewarding and even a bit mind blowing. I’m convinced you’ll have the same experience.
(the reason why I checked it in was so I could continue to bzr pull from Sam’s upstream bzr as I tracked my personal changes in git)
That’s why I suggested starting over with a clean tree. But, if a bit of nasty history doesn’t bug you Sam, then it doesn’t bug me either! And, I’m stoked to see you using git.
If I can get more patches by going with GIT, I’ll go with GIT. I don’t yet know that is the case, but it certainly is worth a shot. We’ll see how it goes.
In order to successfully run the tests, it appears that haml must be installed. I would prefer that haml be optional. Venus does this already for what essentially is the same thing: pluggable shells/formatters. I will make this change.
Even after making this change locally, some tests that previously pass now fail for me. I can’t yet explain why this might be the case. Continuing to investigate.
This is truly a nit. As the number of formatters grows over time, the naming convention of planet/xxxformatter.rb becomes cumbersome. I would prefer planet/formatter/xxx.rb. I’ll make this change too.
If I can get the tests to pass on my machine and use the result to produce Planet Intertwingly, Mars edition, I’ll push the combined changes to my repository.
Venus is made available under the Python license. I’d like to make Mars available under the MIT license. Is this OK with you?
I have been busy running haml + xslt templates and didn’t think about the optionality of libraries on single formatter (e.g. xslt only) runs. I agree that one shouldn’t be required to have haml if it isn’t needed.
WRT the test case errors, I shameless reused your feedparser.rb test driver and top-level variable conflicts appeared. When run separately, they are fine, but in rake they interact. I eliminated some of them, but it seems that feedparser.rb is allowing additional rss test cases (i.e., cloud) into the mix in the rake scenario. I am bug hunting as well.
Having a naming standard for formatters will clean up the directory structure, so that’s good.
And, I’m fine with the MIT License.
Finally, my quick impression is that git is significantly more capable than bzr. Reloading your changes should be no problem.
Cool. I’ll take the opportunity to be lazy then. I’ve started following your fork. If you make even partial progress, I’d encourage you to commit your changes so I can pick up where you left off.
What do you think of packaging Mars up as a gem? It would certainly help with the prerequesites problem. I’ve a half mind to rearrange things so they follow the more standard gem directory layout.
Am also wondering about templating with ERB since it would be pretty brain-dead simple.