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

[Darío Mariani]

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
>