Re: [Tinycc-devel] Development style

[Michael Matz]

Hi,

On Mon, 18 Apr 2016, Sergey Korshunoff wrote:

> > Gosh, and you even put the exsymtab stuff into [mob] now.  Without discussion
>
> http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/threads.html
> (David Martens)

Yes, I know exsymtab, I was there when you both talked about it.  In 
particular I will remind you of Davids own stance towards the exsymtab 
patches:

"I have more work to do on my exsymtab fork before I was going to bring 
it up for inclusion in tcc itself. (Indeed, I am not entirely sure that it 
is appropriate for inclusion in tcc.) Here are a couple of reasons we 
should wait for a little while longer: <list of reasons>".

...

"let's wait a few more months until most of these issues have been ironed 
out and we all have had a chance to discuss the merits and drawbacks of 
extended symbol table support."

So, you single-handedly decided to not have any discussion but instead 
dumped a large patchset into tcc that's inactive by default and where it's 
not even clear that it should be in tcc to start with.  IMNSHO it 
shouldn't.  Certainly not without re-discussing the reason for them, the 
implementation of them and the maintenance impact of them.

> > don't think [mob] is working for you
> > Sigh.  Will decide somewhen next week I guess.
> Very interesting. Who are deciders?

Everyone who cares and commits.  Seemingly we aren't that many anymore.

> > Your fast-paced attention-deficit way of pushing strange hacks into the branch
> A patch was tested a whole year. since 2015.

Sure.  I have patches that implement a sudoku solver.  They are tested 
since 2011.  Should I put them into tcc?

Do you see where I'm getting at?  tcc is not a kitchen sink of stuff that 
you happen to find on the net.

So, please explain exactly what the purpose and merits of these patches 
are, and why it's so important for tcc to carry them that you overrode the 
authors own opinion about not having them in tcc.  This kind of #ifdef 
code is not only ugly but leads to bitrot down the line, so it needs to 
integrate with the rest of tcc by default (without slowing that one down); 
#ifdef should be used sparingly and certainly not everywhere where you 
need SYM_EXTENDED to be removed.  When somebody explains the purpose of 
those changes I'm fairly sure we can develop something that doesn't need 
to be tacked on the side of tcc like a wart and needs 3000 lines to 
implement.  That is all work (in discussion and/or implementation) that 
you should have done _before_ committing something that controversial.


Ciao,
Michael.