Mark Van De Vyver
mvyver at gmail.com
Thu Dec 13 18:53:14 EST 2007
On Dec 14, 2007 7:56 AM, Trans <transfire at gmail.com> wrote:
> Dear devs,
> Per the desires of a number of you to see Og take on a project status
> of it's own outside of the Nitro web framework, I have finally set up
> a development fork for the community to hack on. If development goes
> well, then this can serve as in the future as "Og 2". In the mean time
> the current version will remains safe and sound in the darcs repo for
> production use.
> I've dubbed the new dev-repo "Ogden" for "Og Development Emancipated
> from Nitro" (yea, I just made that up after the fact ;-)
As good as any.
> Whomever would like to be involved in development please let me know.
> I will be coordinating development for the time being --though I would
> like to find someone else with ORM and Og experience that would like
> to take on, at least part, of this duty.
I'm happy to help out with 'chores'.
Not enough of an O/RM or Rubgy/SVN guru to take on a primary role.
> As for a road-map. It remains to be see what the consensus is., but
> I've modified the project TODO list for the things I know. The most
+ If we can get a ogden gem updated daily/frequently then people can use
rubypub.com; i.e. rdoc contributions without hassle/overhead.
- Have specs conform to std conventions, naming, location etc.
(wrecks less havoc with some tools/IDE's)
- Full spec coverage.
+ This may involve rationalization of redundant methods and bug fixes.
+ Are failing specs allowed to be submitted? I'd argue no: they
should pass as 'pending' specs, or be submitted under a bug ticket.
> important of which is to clean up the meta-coding. Currently Og uses a
> good bit of direct code injection, and we need to make these true
> modules instead. I would also like to see how far we can get in just
> simplifying some of the code. Beyond that, the sky's the limit.
Yep I saw what looked like redundant code, but without full spec
coverage it is nerve racking to make any change.
> With regard to the development process, all changes beyond minor fixes
> will be relegated to branches, and we will take care to schedule
> branches to reduce the potential of merge conflicts. So if you would
> like to work on Og and have a significant change in mind, let me know
> and we can set up the branch. For minor changes, of course, you can
> still submit patches.
> Right now I'm finishing up a modification to the way Ogden gets
> required so it won't interfere with Og if you have both installed. I'm
> just about done, and we should be good to go from there.
> Ogden is using an SVN repo hosted on Rubyforge.
> You can of course use SVN directly (as I will be for the time being,
> but I would like to see us move toward using git-svn, so we can still
> share patches is a distributed manor too.
Thanks for all the work in getting this off the ground.
> Let me know if you have any questions.
- as mail list I vote for google groups.
- an irc channel?
> (P.S. if you want dev rights, be sure to tell me your Rubyforge
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general