tinycc-devel
[Top][All Lists]
Advanced

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

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


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

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

reply via email to

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