On Tuesday 12 May 2009, Magnus Lundin wrote: > David Brownell wrote: > > Zack's "list" seemed useful in terms of having some > > kind of direction be defined. But that's distinct > > from defining release criteria, or merge criteria. > > The old list, or the new rebuild everything into loadable > modules stuff?
The last list I saw. Might be time to re-post it. A "libocd" would be one bullet on such a list. > > Right *now*, what criteria are being used to choose > > whether to merge a patch, reject it, or hold it back > > until the next release? That seems like a big un-answerable question ... and thus a significant problem. > > Example: there was a patch a while back (from Dick > > Hollenbeck) that included about 60K of ft2232 and > > TMS sequencing updates ... and gratuitous changes > > to whitespace, and surely other things. I don't > > know of many projects which wouldn't also reject > > such patches with "please split into smaller patches > > so this can be reviewed", as happened. > > > > > Well, since it is more than five days old I suppose it is dead fish. Unfortunate but true. > But I can tell you that all the state transition stuff works well, both > in 7 state version and and shortest path. > There are some issues about PAUSE -> SCAN paths does not go through > CAPTURE, but this path is never used in the present code. What I recall was addition of some logging to help ensure the drivers go through the same state transitions. That seems like an area where regression-testing would be good; not just useful for debugging. > I do not know about high speed ft2232h and ft4232h since I havnt got > any such hardware. I think Amontec should send several of us some free HS jtag keys to help out. What do you think? :) > Reconnect looks ok but not tested. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
