Make Rhino project more active!
Marc Guillemot
what are the goals of the Rhino project? Are committers happy with the
current state?
Personally I'm not happy at all with this lack of activity (1) as we
(HtmlUnit project) need an healthy Rhino.
I understand that current committers may not always have the time /
interest and this is not a critic to their engagement here but I think
that more hands would help the project to progress faster!
So, please make the project more active, invite new committers (2),
improve quality control to facilitate safe changes! From my experience
in HtmlUnit, I can say that new committers *really* help to bring the
project further.
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com
(1) sorry if I don't see everything what you do. My appreciation is only
base on what I can see in the mailing list and with regular update from CVS
(2) this is not a request for myself. If you estimate that I can help
based on the different patches that I've submitted, why not but what
really matters for me is that the project is active.
Attila Szegedi
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.
> _______________________________________________
> dev-tech-js-engine-rhino mailing list
> dev-tech-js-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
Hannes Wallnoefer
> 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.
I have piled up a considerable heap of Rhino patches lately, so I'd
also love to see things getting committed more smoothly. I know
Norris is working on a big AST refactoring, but it would still be nice
to get the small bugs fixed.
I guess I'll have to come out as the one who was afraid of the beast
two years ago when Attila made me that offer. While I'm still very
busy and partially scared, I feel more confident I now about finding
the time and making decisions, especially since I work with Rhino as
part of my day job.
So I'd be willing to become a committer if current committers want me.
Should I proceed as described in <http://www.mozilla.org/hacking/
committer/> or wait for some kind of agreement?
Hannes
> > dev-tech-js-engine-rh...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
Norris Boyd
Excellent! Yes, proceed with http://www.mozilla.org/hacking/committer/
and Attila and I will vouch for you.
I look forward to your help.
--Norris
Hannes Wallnoefer
Hannes
> Excellent! Yes, proceed withhttp://www.mozilla.org/hacking/committer/
Attila Szegedi
> I guess I'll have to come out as the one who was afraid of the beast
> two years ago when Attila made me that offer. While I'm still very
> busy and partially scared, I feel more confident I now about finding
> the time and making decisions, especially since I work with Rhino as
> part of my day job.
That's okay. Most of us work like that. I was really contributing to
Rhino when I was creating a system that used it as part of my day job
too. After a while, it settled into a state where it was Good Enough
for us -- we run half a million (maybe more) instances of big,
nontrivial scripts per day in our systems for the last 5 years or so,
and we didn't hit any bugs for long, long time. I think we're still on
1.6.x ("x" might mean a private build I did sometime from CVS HEAD
still back in the day). So I don't have much of a business case to
hack Rhino at the moment (not that I wouldn't love to, it's just that
things that *now* constitute my business case are entirely unrelated
and suck away all my time).
As for being scared, that's again okay. I was too. I mean, anyone
faced with the prospect of modifying a system of nontrivial complexity
- one that he didn't create in the first place - might be a bit scared.
I take it as a welcome sign that you, in fact, know what is it you
don't know; a sign of a wise person.
But you know, we have CVS. Nothing can be irretrievably broken.
> So I'd be willing to become a committer if current committers want me.
> Should I proceed as described in <http://www.mozilla.org/hacking/
> committer/> or wait for some kind of agreement?
I'm absolutely happy to hear that -- saw your Bugzilla issue, and
already vouched for you.
> Hannes
Attila.
Attila Szegedi
> 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.
Marc Guillemot
> ...
>> 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 remember of it... but I don't think that I've ever seen anything
working there :-(
> 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...).
with CC, I check out in 2 times (in fact 3 as I hold the config app from
a SVN server)
> 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...
thanks for the proposition. As I don't have any experience with Bamboo,
I prefer to make it first working with Cruise Control. Once this work,
it may be easy to have it working on Bamboo as well.
I guess that the root cause of the problems are the huge xml reports.
They have probably to be kept in memory until the tests finishes. A
simple and elegant workaround would be to split the StandardTest. Rather
to produce one huge report, it would be possible to follow the directory
structure of the tests and have one report per directory (or even one
per js test file). If you're interested, I can look at it but this isn't
my first priority as I believe that it should be possible to configure
CC to ignore the "real" logs.
> Alternatively, if you get CC working and up, we can also just
> decommission the Bamboo instance.
;-)
Attila Szegedi
On Oct 16, 2008, at 1:24 PM, Marc Guillemot wrote:
> Attila,
>
> in other words you agree with the bad situation... but can't / don't
> wan't to do anything to change it? ;-(
Just to reiterate from my previous reply - Hannes is joining as a
committer, and my feeling is that I have some involvement in that.
What makes you think I "can't/don't want to do anything"?
> 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.
I'm not 100% decided one way or the other. I'm leaning toward "yes",
though. You're clearly enthusiastic about Rhino. You have HtmlUnit as
a proof you're a competent software developer. I would feel mostly
okay having you as a Rhino committer. As for "mostly" in the previous
sentence -- there's this discrepancy between us in point of view
regarding Rhino's identity. I don't feel at all that we need to pander
to all the quirks of browser JavaScript runtimes that are notorious
for them. That's more code, which is always more liability, and it
might lead to the code structure being more complicated than it would
otherwise need to be.
On the other hand, people are adding JS 1.7 and 1.8 features already,
so Rhino is definitely not a strict "ECMA-262, 3rd edition" runtime
either.
My only worry is that you sometimes view spec-compliant behaviour as a
bug if it doesn't work as it does in browsers. I believe though that
if you develop a habit of checking the behaviour against the specs
(both ECMA-262 and the reference material on <http://developer.mozilla.org/en/JavaScript
> for newer language additions) before jumping the gun, you should be
an okay addition to the project.
Ultimately, my opinion shouldn't actually be too relevant here at the
moment, as my level of involvement with Rhino is quite low lately, so
I don't believe I should be setting policies for how should Rhino
evolve in the future and who would be adequate person to take it
there. If you join as a committer, and your activity takes Rhino
toward more browser emulating behaviour, I would only have grounds to
object if I were actively developing Rhino now myself, which I am not.
It's Norris who's currently leading the project. It's him and people
at Google around him who are doing most work on Rhino nowadays, and
hopefully Hannes from now on; but in any case not me, so I'd delegate
the decision to them. I.e. Norris might decide that he wants to see
more patches coming from you to gain enough confidence. Based on your
enthusiasm and displayed developer skills, I'd be ready to vouch for
you if you can promise to pay more attention to the specs. You need
two vouching current committers to become a committer.
Attila.
Johan Compagner
resource eater.
We switched to teamcity and that was suddenly sooo much more speed and
easier on all the other resources
johan
On Thu, Oct 16, 2008 at 2:34 PM, Attila Szegedi <szeg...@gmail.com> wrote:
> 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
>>
Marc Guillemot
> ...
> My only worry is that you sometimes view spec-compliant behaviour as a
> bug if it doesn't work as it does in browsers. I believe though that if
> you develop a habit of checking the behaviour against the specs (both
> ECMA-262 and the reference material on
> <http://developer.mozilla.org/en/JavaScript> for newer language
> additions) before jumping the gun, you should be an okay addition to the
> project.
;-)
That's exactly the reason why I think that Rhino needs a better build
system. Once features have tests there is no risk to break them because
an other behavior seems better / more logical at some - maybe unrelated
- place.
Johan Compagner
For example we need a lot more classes public or better overridable and
extendable classes (javamembers and so on)
I am also a committer of the Eclipse DLTK (Dynamich Languages ToolKit)
project where i do most of the javascript stuff
also there we needed for debugging in rhino to patch rhino (like
watchpoints)
and also code completion i needed to open up api to get the stuff what rhino
resolved out of rhino (MemberBox stuff and so on)
Last thing i patched was the XML Object toString() thing. I got a big null
pointer when debugging xml objects in rhino
because the xml objects where not complete constructed the right way for the
debugger.
What i could do is to make for many things patches but that will take me
quite some time :(
This are all patches on 1.6R7
johan
On Fri, Oct 3, 2008 at 4:15 PM, Attila Szegedi <szeg...@gmail.com> wrote:
> On Oct 3, 2008, at 3:30 AM, Hannes Wallnoefer wrote:
>
> > I guess I'll have to come out as the one who was afraid of the beast
> > two years ago when Attila made me that offer. While I'm still very
> > busy and partially scared, I feel more confident I now about finding
> > the time and making decisions, especially since I work with Rhino as
> > part of my day job.
>
> That's okay. Most of us work like that. I was really contributing to
> Rhino when I was creating a system that used it as part of my day job
> too. After a while, it settled into a state where it was Good Enough
> for us -- we run half a million (maybe more) instances of big,
> nontrivial scripts per day in our systems for the last 5 years or so,
> and we didn't hit any bugs for long, long time. I think we're still on
> 1.6.x ("x" might mean a private build I did sometime from CVS HEAD
> still back in the day). So I don't have much of a business case to
> hack Rhino at the moment (not that I wouldn't love to, it's just that
> things that *now* constitute my business case are entirely unrelated
> and suck away all my time).
>
> As for being scared, that's again okay. I was too. I mean, anyone
> faced with the prospect of modifying a system of nontrivial complexity
> - one that he didn't create in the first place - might be a bit scared.
> I take it as a welcome sign that you, in fact, know what is it you
> don't know; a sign of a wise person.
>
> But you know, we have CVS. Nothing can be irretrievably broken.
>
> > So I'd be willing to become a committer if current committers want me.
> > Should I proceed as described in <http://www.mozilla.org/hacking/
> > committer/> or wait for some kind of agreement?
>
> I'm absolutely happy to hear that -- saw your Bugzilla issue, and
> already vouched for you.
>
> > Hannes
>
> Attila.
>
> >
> >
> dev-tech-js-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
>