Jonathan Perkin <jperkin%joyent.com@localhost> writes: > * On 2015-02-03 at 01:08 GMT, OBATA Akio wrote: > >> I have no idea how to determine what kind of commits must be proposed/discussed. >> Because I believe that adding "unlink" to tools is very much trivial change than >> reverted commits and such changes was just overlooked. > > Whilst I don't want us to be tied down by draconian rules, my general > approach is: > > - If the change is a simple fix, no need for review. > > - If it's new functionality in mk/ or removal of existing > infrastructure, ask for review on tech-pkg@. > > - If it's new functionality in a non-mk subsystem (e.g. ruby), ask > for review from the language maintainer (e.g. taca) or someone who > has a lot of experience in that area. If in doubt, tech-pkg@. > > That should cover 99.9% of cases. Agreed on not wanting to get very formal. I mostly agree above, but would express it as the following (which I think lines up with jperkin's comments in almost all real cases): 1) if it's pretty clear that everyone will say "I'm glad that's fixed", just commit it. 2) if it seems people will (reasonably) question whether the change is the right one, post for review of course, this won't always work. if something is done without posting for review, and someone says "that should have been posted for review", that's not a big deal - but just feedback that at least one person thought the change should have been handled as (2). Without formal rules, we have to rely on feedback like that to establish how we work together. Sort of related to this is good commit messages and comments in the code. Commit messages should describe the change and explain the reason for it (and why the alternatives weren't chosen).
Attachment:
pgpv5hN2aEyvK.pgp
Description: PGP signature