2014-12-09 11:07 GMT+01:00 Cédric Krier <[email protected]>: > On 09 Dec 10:45, Pierre-Louis Bonicoli wrote: >> On 09/12/2014 01:21, Simon Klemenc wrote: >> > so just in case it becomes even more strict and there is no 8771002, >> > (please?) could you update the wiki, as its not obvious for the dumb but >> > helpful folks... >> > maybe in the coding guidelines it could also be noted that %s is the >> > desired string-format format... >> >> Please, could a core developer list the coding guidelines ? A such list >> would allow faster contributions. > > http://code.google.com/p/tryton/wiki/CodingGuidelines > >> > http://codereview.tryton.org/12491002/ >> > (why not: "please dont fix flake8 from others, they are fixed with >> > 8771002") >> > I really dont want to be bashing but after reading 14761002 i just fail >> > to see the point of doing open source without accepting different >> > opinions + i feel a little ashamed... >> >> Generally, in order to allow faster contributions, core developers >> should avoid writing opposite comments in review. Better reviews will >> result in better contributions. >> For example, in 12491002, comment in patch set 3 about "ValueError" >> could have been written in patch set 1, it would have avoided a patch >> set. Moreover this will avoid giving impression that contributions are >> not welcome. > > That's a dream. Or I will just stop reviewing.
Or in other words: It's impossible for the reviewer to see all the possible problems at the first review, the same way the creator of the patch didn't see those in the first place. Otherwise it would not be necessary to review at all. Reviewing takes time and most usually several uploads and that's why the quality ends up being great. -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
