Hello Michael,

On Sun, Oct 16, 2016 at 5:59 PM, Michael Matz <matz....@frakked.de> 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. :-)

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
Tinycc-devel mailing list

Reply via email to