Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA.
As far as I understand the only person who answers for the commit is a committer. So I don't think that establishing a policy that shifts a part of responsibility from the committer is a good idea. Well, I have another silly question to gurus indeed. Is there any possibility that some piece of code can break / hang the release build if it passes ok on the debug build? Thanks, 2006/11/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > I can understand that the contributor may not have access to multiple > platforms, but surely he can test using both debug and release builds :-) > What do we gain by asking the contributor to test less? > > Rana > > > On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > > > +1 for debug testing before submitting a patch. > > > > But, for pre-commit testing we should be careful saying we'll test all > the > > patches in debug mode. Though it imprves quality of checks, debug build > is > > significantly slower then release, especially when running with > > interpreter > > or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and > it > > takes about 5 times more time than release version on my laptop, The > times > > were as follows: > > > > "build test", Windows XP/ IA32: > > DRLVM release: 22 min 55 sec > > DRLVM debug: 99 min 23 sec > > > > So, may be the good choice will be to ask patch submitters to check > their > > patches on the debug build and, if the JIRA issue contains comments that > > this check is passed, committers may test it on release build only. > > > > Thanks, > > Pavel > > > > On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > Well, since the problem is repeatable.... :) > > > > > > > > > Gregory Shimansky wrote: > > > > Geir Magnusson Jr. wrote: > > > >> > > > >> > > > >> Alexei Zakharov wrote: > > > >>> Hi DRLVM fans, > > > >>> > > > >>> I encountered a rather strange problem while working on some class > > > >>> library tests. At least two tests from the beans module hang (or > > > >>> crash) while running on DRLVM debug builds but work fine on DRLVM > > > >>> release builds. I thought that debug build is something about > adding > > > >>> debug symbols to VM binaries and this should not affect the > > > >>> functionality. Can someone shed a light on this? > > > >> > > > >> I would think it's just an assertion firing... > > > > > > > > Actually it is more than that. In debug mode TRACE statements are > > > > compiled and therefore produce executable code. There may also be > some > > > > bugs in compiler generating code in different modes (although this > > > > usually happens for release). > > > > > > > > I don't know why hanging happens, but the difference in generated > code > > > > is actually quite big. Also assertions or any crashes go to > > > > exceptions/signal handlers which may happen to loop infinitely, > there > > > > were bugs like this happening on the current version of sources, > look > > at > > > > HARMONY-2018 and HADMONY-2006. > > > > > > > >>> This is the first > > > >>> question. The second question - what we should do with such tests. > > The > > > >>> tests pass on the downloadable HDK and JRE snapshots as well as on > > > >>> classlib + j9. What should be the commit criteria for DRLVM – i.e. > > > >>> what is the *true* build? :) I think many people here currently > use > > > >>> snapshots to test their patches. > > > >> > > > >> debug :) don't sweep the problems under the rug... > > > > > > > > +1
-- Alexei Zakharov, Intel Enterprise Solutions Software Division
