[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Development/patches - subversion repository

From: Rob Landley
Subject: Re: [Tinycc-devel] Development/patches - subversion repository
Date: Thu, 14 Sep 2006 14:00:20 -0400
User-agent: KMail/1.9.1

On Thursday 14 September 2006 12:08 pm, Nick wrote:
> Hi Fabrice, Rob,
> Fabrice - thanks for making TCC open-source - great project!


> 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 

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?

Never bet against the cheap plastic solution.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]