Re: [Tinycc-devel] Development style

[David Mertens]

Hello Michael and Sergey,

I have nuked that commit. I'm sorry for altering the history of a public git repository, but that commit was not appropriate, and it's better to fix it quickly now than to live with the consequences or a rash commit.

exsymtab is a huge addition to tcc. It should not go in without a serious discussion and code review. No such discussion or code review took place. In fact, Sergey, you didn't even push your proposed work to a feature branch as dictated in step number 5 of the instructions.

For time management reasons, my recreational programming goes through a distinct email account, one that I hadn't checked since early January. It might have looked as though I had abandoned my work on exsymtab. I have not, I just put it on hiatus. Today happens to be the day I've checked back, and wow, what a day.

I am not yet ready to discuss adding exsymtab to tcc; I likely won't have time until this summer. If others want to take up that conversation, that's great, and I'll try to follow the conversation moving forward.

Sorry for popping up out of nowhere and potentially causing damage. I believe it's for the better.

David

On Mon, Apr 18, 2016 at 5:58 PM, Michael Matz <address@hidden> wrote:

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.

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--

 "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