On Wed, 22 Jun 2016, Paul Jakma wrote:
- Those who do their best to make contributions easier to review,
particularly more complex ones, with _good_ commit messages about
the approach and any arch. issues, and who provide a decent map of
the intended changes.
- Those whose approach to comments on nits and architecture and what
not is to just address them by making the change or through
persuasion by constructive discussion.
And I just don't understand why either of those things could be an issue
for anyone.
How on earth can it be reasonable to have large, complicated patches
with non-obvious impact on user-visible behaviour come with just 2 or 3
lines of explanation, and be annoyed at being asked to provide a bit
more information?
It's a 2-way street, if reviewers and integrators have to get through
more patches and improve, then contributors doing more work up-front to
provide information to make things easier to review, and easier to
apply¹, has to be part of the answer to making things scale up.
1. E.g., if every other commit in the history starts with a short
subject line, prefixed in some kind of 'tag: ' fashion where 'tag'
tends to be from a small set of things, how difficult can it to just
stick with convention (which, gosh, perhaps exists for a good reason)
and do the same? Instead of not doing so, and forcing the integrator
to have to manually edit the thing, or push it back?
(If only this were already documented somewhere, like in a document
people should try read before contributing... We could even keep
such a document in the very repo).
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Of course I can keep secrets. It's the people I tell them to that
can't keep them. -Anthony Haden-Guest_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
