 |
 |
Andy, > It is mostly about checking if the code is clean, if it follows lsst coding standards; we also use it as a vehicle to learn from each other. You don't need to do any verifications whether it works, this is up to the person writing code. We try to keep reviews lightweight, e.g. an hour or two, but sometimes we break this rule and end up with monster reviews, like CSS. The name space review should be quick, I hope. > > I'm sure KT will chime in about the review process :-) https://dev.lsstcorp.org/trac/wiki/CodeReviewProcess but this has not been updated to reflect several things. We are now having developers self-assign reviews to people usually in different teams. We're not generally doing interactive/face-to-face reviews, but they may be appropriate for very large reviews. Alternatively, it's a good practice to split up a large review into pieces that can be handled by different people. And of course we're using JIRA for new issues, not Trac. Still, the goals are the same, and write-ups should still be in either Trac or JIRA. No review results should be in private E-mail. -- Kian-Tat Lim, LSST Data Management, [log in to unmask] ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1