On Oct 16, 2008, at 1:24 PM, Marc Guillemot wrote:
Attila Szegedi wrote:
I agree with the sentiment. I quite obviously can't find time to
work on
Rhino for months now. Norris does actually work on it from what I
can tell.
I would love it if we could attract new developers; the thing is
though
that Rhino is a volunteer effort (as most OSS projects are).
Soliciting
volunteers sounds a bit like a contradiction in terms to me. If
someone
is enthusiastic enough to want to be a committer, it is they who
need to
reach the decision and come out with the intent. If I'm soliciting
people to become committers, then where's the volunteer enthusiasm in
it, right?
We need people who understand the Rhino codebase, and know the
ECMA-262
spec. I actually have a favorite candidate for a new committer for at
least the last two years, judged by quality of patches submitted to
Bugzilla. I actually asked him about two years ago already if he
would
like to become a committer, but he politely declined then, citing
how he
has just enough work on his hands (which is a perfectly respectable
and
valid reason; not that anyone needs to actually explain themselves
for
*not* wanting to volunteer for something). I won't cite a name, you
know
who you are, if you changed your mind, I'll still gladly vouch for
you
on your commit access request.
Attila.
Attila,
in other words you agree with the bad situation... but can't / don't
wan't to do anything to change it? ;-(
Well, Hannes is in the process of becoming a committer; I have quite a
lot of hope that that's going to cause a change.
Then, to try to change things a little bit, I ask here if you want
me as
new committer. I'm surely more interested in making Rhino working like
most browsers do rather than following strictly ECMA spec, but I think
that both are valuable goals for Rhino and that they are not
incompatible.
Let me get back to that separately.
Independently of the previous point, I'd like to help improving the
quality of the project. With this I mean that the quality relies too
much on knowledge of some individuals rather than on automated tests.
I've already written my view on this and I still think that Rhino
needs
urgently a build system on which we can rely. For this purpose I've
started to setup a Cruise Control instance for Rhino that is hosted by
my friends of Canoo AG (http://www.canoo.com, they already host CC
instances for HtmlUnit, WebTest, Grails, Groovy, ...). I can't yet
post
the url as the huge output produced by the StandardTests causes
problems
to CruiseControl and I have first to find a workaround. I can
configure
the build to post results to this mailing list if there is interest
for
it. Naturally the build fails currently as many tests fail :-(
As a matter of fact, I secured an Atlassian Bamboo license to use with
Rhino, and got us provisioned a server managed within Mozilla
infrastructure more than a year ago for purposes of running it. I
believe I did announce it at one time or another on this list. It is
at <http://cn-rhino01.nl.mozilla.org:8085>.
I installed Bamboo on it and configured it to pull Rhino from CVS
(also a problem being that we can't just pull js/rhino module, we need
to pull js/tests as well, and Bamboo doesn't anticipate that, so we
need to pull js/* and filter out what we don't need; anyways...).
The problem is, it regularly runs out of memory. The server (which is
a virtualized server, I believe) has 512M of RAM allocated, which I
hoped would be more than enough to build Rhino and run tests, but it
apparently ain't so, the standard tests indeed are a memory hog.
Bamboo is already set up to run with -Xmx512M (obviously spilling over
to swap when it reaches near that figure). I spent a weekend on trying
to remedy the situation, but didn't succeed.
(I've just bounced Bamboo and now it runs the tests, you can check the
Activity tab... I'm afraid it'll however just drop the ball eventually
when it runs out of memory).
Splitting up tests to run in separate JVM instances would probably
help even if it'd make everything much slower (not that it matters
much with a CI tool). Anyway, I can set you up an account on it (both
the machine and the Bamboo) if you feel like wrestling with this. I
still think 512M should be enough on the machine, and since it runs on
a shared physical Mozilla funded hardware, I'm reluctant to go and ask
for more resources...
Alternatively, if you get CC working and up, we can also just
decommission the Bamboo instance.
Attila.
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
