[Nitro] Retrospective and future direction.

Kashia Buch kashia at vfemail.net
Wed Apr 19 15:36:22 EDT 2006


Hi,

> Toward this end I have a couple of questions:

might as well try to answer, take it with a grain of salt, I'm higly
biased ;)

> 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.

=being # half burnt, don't read ;)
I see it this way:
If there is a tool which fits the project perfectly, why chose a solution
which is less suited?

There are always discussions about the best VCS, none of them ever lead
to anything, I am aware of that.
No really, darcs has got quite some followers now, and will eventually
attract more users, when people finally realize that CVS is not the only
way to go.
=end

You mentioned that Nitro has a different mindset than Nitro, which I fully
agree to. But I also think that this mindset extends to the surroundings
of Nitro as well, meaning the development style and the current community
in general.

> 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

Hmm... now that nitroproject.org is "almost" up, nitrohq.org catched from
James and Oxywtf, things are starting to get real better :)

For Oxyliquit being off track, how do you mean that, and do you see a
solution to make it more "common"?

> 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 ?

We have Brian, I loooove him ;D
Yes yes, I'm sorry ;)
No really, people really get more emancipated over time :P

> Diagrams that cover the overall architecture would be very nice to

I agree to that, wasn't there an attempt earlier... I gotta dig that
up and put up to oxy. Thanks!

> have.  And a good philosophy statement, preferably delineating what the
> Nitro/Og projects are and are not very clearly.

Hmmm... I'm not really sure what you mean here, could you rephrase for a
non native?

> 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.

I sure hope he first finishes his  own page, until then I hope he will
mention nitrohq.org/oxyliquit.de and let them make a note of nitroproject

> 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.

Native? none :)
But afaik it uses Threads 'n stuff, where they supported by Java?
I think, now that Yarv is almost finished, maybe I could test running
Nitro with that :)

> 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 Linus Torvalds said once: "As a project maintainer my job is to reject
new funny patches, not to accept every single one"
(Not an exact quote)

At the moment the standard way to contribute, is the following:

* Send to mailing list / trac
* Brian will merge it if you ask nicely ;D
* Brian posts question, if others have problems with patch
* A few people answer
* patch gets used by a few people :P
* patch ends up in repo

Note that this is not meant to be a definite guide, more a joke ;)

If you have any ideas on how to unify processes (sounds like UML, yuck)
just go ahaid and outline what you think :)

And overall, your input is very welcome, keep it coming ;D

Kashia

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png



More information about the Nitro-general mailing list