Re: [Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

Hello Michael,

On Sun, Oct 16, 2016 at 5:59 PM, Michael Matz <address@hidden> wrote:

<snip>

You can't "move" tinycc anyway.

Of course not. There are only a handful of folks who really understand the inner workings of tcc (you being one of them), and if they want to stick with repo.or.cz, then that's where code will stay. Nobody can forcibly move the project anywhere.

 

<snip>

Currently I don't see the need for gate keepers (though I certainly was extremely frustrated during at least two periods in the past where low-quality non-sense was added).

Sure, tcc itself does not need a gatekeeper. Unwanted commits can easily be overturned. But, since tcc does not support extensions, it implicitly forces extensions to be maintained as forks. This is what I do with my extended symbol table project. Keeping forks up-to-date with mob is a huge pain. A pull-request style would make the code much, much cleaner, and thus my job much, much easier.

I wrote a much wordier statement, but I'm trying to learn to be more terse. See below if you want to read more. :-)

David

Consider the following tcc policy:

* Nontrivial extensions to tcc should be maintained as separate forks.

That statement is not explicitly stated anywhere, but it is consistent with how the tcc project maintains itself. Anything outside of tcc's main goal---fast one-pass C compiler and linker---do not belong in this project. As a corollary, any nontrivial extension to tcc should be maintained in a fork. Or, there shouldn't be any nontrivial extensions, but that's not realistic. So, I will take that as my premise.

The current situation is very precarious for extension maintainers like me. This precariousness has been pointed out before: https://lists.nongnu.org/archive/html/tinycc-devel/2014-05/msg00036.html. In a related but separate story, I started my extended symbol table work back in the fall of 2013. When I checked back in over the summer of 2014 (when Sia was writing that email about jiang's commits), mob had an enormous number of low-quality line changes, and it no longer compiled on Mac, so I didn't go through the effort of updating my fork. The situation got worse and worse until I was saved by seyko's heroic efforts and a major pull-request on my project.

Still, my efforts to track my nearly-up-to-date fork with mob are subject to the whims of contributors who cannot or simply do not test their commits on multiple operating systems, or who commit a series of half-completed commits that break git-bisect. Or, suppose somebody contributes high quality but unwanted code that touches something I've altered. Even if that commit is later reverted---keeping tcc slim and the final state of the sources in good shape---I still need to merge the initial commit and its revert. I would be much, much happier if these reverted commits were never added in the first place.

--

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan