I agree with Juha. I would even take it further: No commit should be done without referencing the corresponding issue the commit is related to, i.e. issues should drive development, not the individual developer's to-do list. Without these two rules, we have no transparancy on what is going in development (or as today: the maintainer's head) and no transparancy on what did go in development (or today: no documentation).
These are just natural consequences when a project has multiple developers. Also, this will help out in communication across developers. g-)
Juha Heinanen wrote:
Jan Janak writes:
Are you suggesting that commits should be rejected if they do not update documentation as well ? What is better, having undocumented code or having no code ?
yes, i'm suggesting that no commit should be accepted without corresponding documentation. otherwise the new features become secrets of the chosen few who have read the code and understand how to use them. the rest will fill the mailing list with questions.
-- juha