We (wicket webframework) also used to use Bamboo but that is a horrible 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 <[EMAIL PROTECTED]> 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 >> > _______________________________________________ > dev-tech-js-engine-rhino mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino > _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
