Tim, Thank you for explanations. I'm not suggesting to reject a contribution. I like an idea of Mikhail's algorithm which checks data flow, though I failed to understand how subroutine boundaries in one pass. I missed any reference to this in documentation as well.
Accepting here does not mean this contribution will be the one and only bytecode verifier going forward.
We agreed to keep duplication out of Harmony. I personally believe we need strong arguments for any duplication, and I do not see enough arguments to have two verifiers. Honestly, the thing I'm trying to avoid is a loss of my precious life time. Currently I was looking into bugs in existing verifier, but there are many other interesting things as well. I would be grateful if any decision is taken on verifier replacement, merge, or whatever. On 5/31/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Alexei Fedotov wrote: > What do you mean by accepting? Does it mean that you want to commit it? Accepting means that - pmc members have had a chance to verify the basis of the contribution (through accompanying paperwork that is not generally available to all) - everyone gets a chance to express an opinion about whether the contribution is in keeping with the goals of the project We are interested in any reason why people think we should not accept this code. The vote is conducted in public so everyone gets a voice. We just ask that if you vote 'reject' you also tell us why. Once accepted the code can be committed into our SVN repository, but that is not the end of the discussion and evaluation. Collectively we may then decide that the contribution is new functionality that simply adds to the existing body of code, or that we should replace existing functionality with the incoming contribution, or that we maintain it as an alternative implementation, etc. Accepting here does not mean this contribution will be the one and only bytecode verifier going forward. Regards, Tim
-- With best regards, Alexei, ESSD, Intel
