On 20-04 14:16, Juha Heinanen wrote:
Jan Janak writes:
For new code maybe, but I wouldn't be so
picky about existing code. I do not
want to throw away stuff that already exists just because it is not
documented.
yes, i need to soften my position.
undocumented features just makes merge much harder, because it is not
enough to compare readme files. also, it more or less means that the
party who has not documented its features needs to make the merge,
because that party understands what the undocumented features are
doing.
Nobody said it would be easy. I too had my share of this while I was trying to
convert kamailio modules. Not everything can be documented in readmes, for
example, there is a lot of changes in kamailio internals that I didn't
understand and I had to ask Daniel, Henning, and others.
If you need to find the author of a particular change then you can use 'git
blame' and talk to them directly. But I am afraid there is no way around
browsing through the code and trying to spot what is different.
But yes, I find it reasonable to ask from people that all new code must be
documented somehow (readme, wiki,...).
I prefer README as authoritative source - every feature commit should
also add a feature descrption (e.g. do not write long commit messages
but write the text into the README and then copy paste it into the
commit message)
regards
klaus