On Feb 8, 2009, at 6:57 AM, Ben Laurie wrote: >> Without making comments on the rest of the patch (which looks >> similar to the >> other parts), I think there just needs to be a high-level comment >> of what is >> the algorithmic model for the constraints, how they are resolved, >> what is >> represented, etc. Right now it is difficult for me to evaluate the >> approach >> itself since I don't really understand the algorithm. Also, I >> think that >> the implementation itself should come in a straightforward manner >> once a few >> key methods (e.g., "CouldBeEQ") get fleshed out. I'm more than >> happy to >> help with this process. > > How would that work in practice? Without switching to mercurial, > that is? > > Anyway, will work on a new version of the patch.
I personally love distributed version control systems, and maybe one day LLVM will use one (a prerequisite being that someone volunteers to set up all the needed infrastructure). That said, I don't think that's necessary for collaboration. LLVM (and clang) developers through a very rapid prototyping model. We prefer incremental patches that stub out an implementation, and have pieces of functionality gradually working over time. It has worked very well for bringing up countless features in both LLVM and Clang involving many contributors with disparate ideas. For contributing to the static analyzer, I've tried to make the design modular so that pieces can be swapped in and out. A new RangeConstraintManager (or whatever is called) can easily be slotted in as a separate .cpp file that gets implemented in pieces. Subclasses of ConstraintManager implement a specific interface, and when prototyping a new ConstraintManager one can just assert on cases that are currently not supported (this is a great way to test an implementation as it evolves). As pieces get added, e.g., to support '>' or '<' constraints, test cases can get added to the test suite, etc. Mechanically, this process would consist of incremental patch submission and review. After a contributor has provided a few significant patches to the tree they are then granted direct commit access. This access is initially commit-on-approval (i.e., patches must be reviewed) and then as the patches reach a point where the contributor clearly understands the coding standards, the impact of their patches, etc., patches are then reviewed after they are committed. For significant patches that may change many things, you'll notice that even regular contributors frequently send out their patches for review, particular if their is a question regarding its design or implementation. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
