[ODE] Patch for eliminating penetration bounce mega-force?

[Megan Fox]

Would a reasonable approach be to adopt unit testing?

It seems as if physics is one area that is rather well-qualified for
that sort of approach... set up your various sims (which could easily
be demo programs themselves), seed them with start values, run the
sim, grab ending positions, compare to known desired results, flag if
error occurs or results are different than expected.

This is assuming ODE can indeed manage repeatable sims - I believe it
was said it can, just takes a bit of work?

-Megan Fox

On 6/2/05, Darío Mariani <mariani.dario at gmail.com> wrote:
> I agree, the problem seems to be that the resources for patch
> verification are scarse (only few people without time to spend on it),
> and a different aproach should be used. How do other projects do this?
> For instance, KDE is a big monster, and I do not think that patches
> are tested one at a time.
>  May be a simple web application could be created were patches are
> submitted and can be downloaded for testing and confirmed they work or
> not, then moved to unstable branch and rechecked.
>  Another, more clean aproach is to create tests, you start with a
> library that pass a set of tests, when you apply the patch, the test
> should run for the patch to be accepted, and it must provide new tests
> for the next iteration.
> 
>       Darío
> 
> On 6/2/05, J. Perkins <starkos at gmail.com> wrote:
> > On 5/31/05, Jon Watte (ODE) <hplus-ode at mindcontrol.org> wrote:
> > > I think, at the larger level, the problem is that there are three kinds
> > > of people on this list:
> >
> > Perhaps part of the issue is that the people with commit priviledges
> > feel obligated to verify each patch, and they don't have time to do
> > it? (Pehaps I am wrong, in which case you can ignore everything that I
> > am about to say). I think that the community would be more than
> > willing to help; perhaps we need a better defined patching process?
> > Just to get the ball rolling, maybe something like:
> >
> > 1) submit a patch to this list
> >
> > 2) patch is peer reviewed. At least one (or 2 or 3) other people must
> > verify that it works as verified.
> >
> > 3) patch is checked into the unstable branch by the patch submitter
> > (or a proxy if the owner isn't comfortable with cvs).
> >
> > 4) the community tests against the unstable branch. This is the part
> > that makes the maintainers uncomfortable I imagine; the community has
> > to accept responsibility for getting this done.
> >
> > 5) after two weeks (or whatever) of testing and bug fixing, the
> > changes are merged into the main branch. If the patch fails
> > acceptance, then the branch is rolled back to the last tag.
> >
> > Only one patch can be in-process at a time, but it would still be much
> > better than the situation we have now. The maintainers would only have
> > to ensure that the process is followed, instead of actually verifying
> > the patches themselves. The gist of it is that if patches need to be
> > tested before they can be accepted, then give us a definition of
> > "tested" that we can work toward.
> >
> > I fall into the "hobbiest" category right now though I am working
> > nights-and-weekends toward a commercial product, of which ODE is a
> > small but important part. It is a great library and I would hate to
> > see the community abandon it; I would happy to build against unstable
> > if it improves the codebase. I don't like applying patches to my code
> > without some idea if it will ever make it into the main distribution.
> >
> > Hope this helps someone,
> >
> > Jason
> >
> > _______________________________________________
> > ODE mailing list
> > ODE at q12.org
> > http://q12.org/mailman/listinfo/ode
> >
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>