[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