David
On Tue, Jul 25, 2017 at 12:31 AM, David Mertens
<address@hidden <mailto: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
------------------------------------------------------------------------
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel