[Nitro] Nitro Development

TRANS transfire at gmail.com
Sun Oct 22 13:18:30 EDT 2006


I think the source of problems with the repository and communication,
as well as the constant turnover of developers, derive from one simple
fact. Nitro/Og is still largely George's personal project --much of
Nitro/Og is still subject to major overhauls at George's personal
discretion. There's nothing wrong with that in itself. Every project
must go through an initial phase of this. But at some point George has
to let go of the project in the sense that he alone no longer controls
it's destiny. George will of course always have a major influence, but
he no longer can simply change something because he feels like it. It
is absolutely mandatory that that he consult with the community --as
is the case for all developers. Going off and making a patch with
consultation is risky business. Too much that and you have a mess.
So likewise, there must be ONE central repository that all changes
merge back to. It doesn't really matter which rcs is used. Darcs is
fine, but good practices must be maintained --that's key. Also, baby
steps must become the norm. Each release should focus on ONE
significant change. I also think  that every other release should be a
clean-up, fix-bugs, improve docs and improve tests release which then
would also be an "official release". So something like this:

  - introduce more patches from manveru's repository
  - cleanup-release

  - make postgres adapter run

  - clean-up release

  - make examples run

  - clean-up release

  - make compatible with latest facets (esp. the new annotation system)

  - clean-up release

  - introduce new system part / get rid of old scaffolding.

  - clean-up release

  - make new deployment scripts

  - clean-up release

Mind you, that's not to say other things won't get into odd releases,
but they can only be small changes. All significant changes need to
get there own release scheduling.


More information about the Nitro-general mailing list