On Thursday 14 September 2006 12:08 pm, Nick wrote: > Hi Fabrice, Rob, > > Fabrice - thanks for making TCC open-source - great project!
Seconded. > I have a few patches to post as well. Step 1 is to collect patches. I'll take a whack at it this weekend. > A good wedge only has one point. Good advice if you want a wedge :-) > > If people are using TCC, and take the time to fix something, then their > goal is to make things better (unlike the Wikipedia example where not > everyones goal is to make things better). > All patches should be posted and reviewed. Testing can be handled by > submitter running the tests (if they have the setup), or by commiting to > a "test-pending" branch that gets merged to the trunk every few days > after a test run by someone who does have the test setup. TinyCC is small and simple. I linked to the "fear complexity" thing for a reason. Complexity is a cost. > I figure people won't abuse checkin privileges, and if they do, just > back out the problem. Write access requires a login and password so > everything is tracked by author. There really is more to maintaining a project than that. Honest and truly there is. Most authors mean well, but most changes have problems. Often they are conceptual problems, the problem they're trying to fix is real but they take the wrong approach. The right fix is sometimes a completely different patch, and sometimes there are several ways to do it which will work, but you have to pick _one_ way or they'll interfere with each other. There's a big difference between "that patch shouldn't go in" and "that author is acting with malice". > Much of my day job is working on/developing closed source code. Everyone > in the company has the goal of improving things and we don't need or use > a wedge for checkins. So nobody is in charge of the project? Nobody sets goals? There are no areas of expertise you defer to each other in? Nobody says "this code works but is illegible, clean it up before it goes into the tree"? Nobody resolves disputes about the best way to accomplish something? Nobody prioritizes competing goals? Right now, TCC's main advantages are that it's fast and that it's simple. I think it needs to grow more capabilities (so it can compile complete projects as a drop in gcc replacement; it's so close it's a shame _not_ to go the rest of the way), and it would be nice if it had the option (but not the requirement) to spend more time compiling in order to produce more optimized output. If people just start attacking the optimization and feature problems, they can easily slow TCC down for everybody, and double the size of the code even for people who don't want the optimizer. Somebody has to worry about keeping the code clean, fast, and understandable. This is a good maintainer's job. > It would also work by having a volatile trunk/branch and for Fabrice or > a maintainer to do the final review and release management. The diff for > a release could be applied back to the CVS version if desired. So nobody should ever actually make a decision about what should and shouldn't go in? Rob -- Never bet against the cheap plastic solution. _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
