[Nitro] Retrospective and future direction.

Bryan Soto bryan.a.soto at gmail.com
Wed Apr 19 18:10:58 EDT 2006

On 4/19/06, Dylan Bruzenak <dylanb at digitalvalence.com> wrote:
> One of the directions I'd like to see the project go is making it easier
> for new people to get into the code base and contribute.  The success of
> a project like this depends entirely on its community.  There is a great
> group of people here already, and making the party bigger (along with
> improved docs to provide direction) can only help accelerate growth and
> adoption.  Although the necessity of 'competing' with a project like
> rails is dubious since NitrOg seems to follow a different set of
> principles, the success of that project cannot be ignored as a model.
> And it is dominant in large part because of its massive contributor
> community, both in the form of direct committers and plugin developers.

All of this is very true. An open-source project lives or dies by it's
community and anything we can do to help foster it is a good thing.

> Toward this end I have a couple of questions:
> Why does Nitro use a non-standard source control system ?  I was able to
> get it up and running fine, and it seems very nice, but everyone already
> has CVS (and many have Subversion).  They don't need to download or
> learn anything new to use it.  Using a non-standard system hinders
> adoption and contribution.

Well, the why would be for George since he choose it. All I can say
is, as a previous CVS person, I rather like it now. Sure, it seemed
like a pain at first, but I didn't really need a major push to
download something new... Besides, with Pugs being hosted in it, I
think it'll become more popular.

> As for documention, I've been distracted with other things - is the wiki
> fixed yet ?  Or is Nitro moving to oxyliquit as the primary
> documentation repository ?  With NitroHQ gone and oxyliquit off the
> beaten path and therefore difficult to find, many people would probably
> be excused for thinking this project was dead, rather than heating up.
> Perhaps someone can take charge of the minor administravia in order to
> take the weight off of George's overburdened shoulders ?

There will be a new website, nitroproject.org. I don't know what
George has planned for it. George also mentioned on #nitro that he
would figure something out in regards to admining the server. We can
only hope. :)

I don't know if George is planning for oxyliquit to be the official
source for docs. At the very least, it is a very good unofficial one.

> Diagrams that cover the overall architecture would be very nice to
> have.  And a good philosophy statement, preferably delineating what the
> Nitro/Og projects are and are not very clearly.

Diagrams would be good. Does anyone have any suggestions for
diagramming software? Windows or Linux. Preferably free or
open-source. And for philosophy, George do you have one for Nitro/Og?

> I hear George is going to Athens or something to give a presentation.
> That kind of profile expanding behaviour would be very helpful once the
> website details are sorted out.  If you get people interested and they
> come in and have no site to go to, you are going to lose most of those
> new people.

Yes. I'm glad George decided to delay the release until he got a new one set up.

> How much native code does Nitro use ?  The JRuby geniuses almost have
> rails running on the VM; it would be nice to have 'something doing' in
> that regard.  Not terribly important, but nice.

The only portions that are native code would be extensions like
fastcgi, the database driver, etc.

> As to the speed of patch application, is there a way to speed this up ?
> Is this a time constraint issue; a patch review time issue, or what ?
> How do other projects handle these details ?  Also, is there a policy of
> having to have a test for new features so that they can be easily
> demonstrated and verified by the patch 'applicator' ?  What with the
> flurry of submitted patches lately, there has to be some standard way of
> checking for conflicts and notifying the competing contributors so that
> a solution can be worked out.

As of yet, we haven't had competing contributors. :)

I think the bottleneck is that I'm currently the only one reviewing
and applying them. Trying to balance that with fixing bugs when I only
get a few hours a day to do anything Nitro related just isn't working.
Reviewing patches is actually a pretty good way of becoming familiar
with the code base (it's how I started), so if there's anyone
interested in helping out, please let me know.  :)

For submitters, tests are expected, whether bugs or enhancements. For
an enhancement, docs are expected as well.

"Never tell people how to do things. Tell them what to do and they
will surprise you with their ingenuity." —General George S. Patton

More information about the Nitro-general mailing list