tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] Please, please at least notify the list when you make


From: David Mertens
Subject: Re: [Tinycc-devel] Please, please at least notify the list when you make big changes
Date: Tue, 25 Jul 2017 00:54:48 -0400

Case in point:

I just tried to merge grischka's latest commit, described as "tccgen: nodata_wanted fix, default ONE_SOURCE, etc...". I have no idea why, but with the commit grischka decided to move a whole bunch of functionality out of libtcc.c's tcc_compile() and into tccgen.c's tccgen_compile(). Is this a good idea? Maybe? It makes tcc_compile read a little more clearly, though the real functionality is now buried under one more layer of abstraction. I don't know grischka's motivation because he never explained what he's doing or why.

What I do know is that now two of my tests segfault, and I'll probably have to spend a couple of hours reverse-engineering how to track the symbols.

Hours of my life wasted for what seems like a frivolous change.

David

On Tue, Jul 25, 2017 at 12:31 AM, David Mertens <address@hidden> wrote:
Hello all,

This is my annual (or so) rant/reminder urging everyone for high quality committing and communicating habits.

As a maintainer of a fork of tcc, I go through a lot of effort when I merge the latest work on tcc's mob into my fork. This is a burden I have brought upon myself, and I am not complaining about folks' contributions to tcc that continue to improve it. However, there are ways to improve things (i.e organize, commit, and discuss your work) that are easy to process, and there are ways to improve things that are hard to process.

If you want to see practices that are easy to process, look at Michael Matz's commits and the conversation surrounding them. If you want to see commits that are hard to process, see grischka's unprompted commits.

Let me be clear before I go any further: the final result of grischka's commits are almost universally excellent. He wields C much better than I ever could, and I would rather have his commits as he currently does them than not have them at all. Specifically, grischka latest work refactoring the Sym layout is a fantastic contribution that makes this compiler easier to understand for current and future tcc hackers. It's the kind of think that everybody would like to have, but nobody except grischka will put the effort into doing. Thank you!

But lordy I would really appreciate if he (and the rest of the community) could consider the following basic good-git practices:
  • orthogonal changes should be in distinct commits, don't commit "X... and also Y, Z, and W"
  • changes to any of the internal function APIs should be (at the very least) announced on the mailing list, and preferably discussed
  • changes in where and how functionality is implemented should be announced on the mailing list, and preferably discussed.
  • changes to public API functions *really* *should* be discussed on the mailing list before being committed
  • changes to the build process *really* *should* be discussed on the mailing list before being committed

Why should you do these things? Because right now I cringe before I try to merge any commit made by grischka. I know the result will be worth it, but the interim will probably be time consuming and confusing. Do you want to be cringe-inducing to fellow developers? Of course not. Discuss your work on the list and commit your work in lots of small chunks.

Thanks!
David

--
 "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



--
 "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

reply via email to

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