CTR can be done with the commits@ list, but with git it can be way too noisy to follow or understand. Pull Request have very good UI for code review. I think we also have an ASF Gerrit instance we can use.
How about we do RTC for large things or where a committer is not quite sure, but CTR for maintenance things? Also I would put an informal 1w deadline on any pull requests after which the committer just merges themselves. On 4 Nov 2016 11:48 am, "Andy Seaborne" <[email protected]> wrote: > There are two styles > > CTR - "Commit then review" -- its still up for review > RTC - "Review then commit" > > and hybrid forms such as committers doing CTR for small, "obvious" things > (e.g. "Doh!" bug fixes; emergency repair) and RTC via PR when larger or the > committer is seeking review. > > Andy > > On 04/11/16 04:11, Thilina Manamgoda wrote: > >> HI, >> >> I think this is a good idea. There may be mistakes in my code because >> still i am not a expert thus code review is a good approach. >> >> Regards, >> Thilina >> >> On Thu, Nov 3, 2016 at 10:05 PM, Ian Dunlop <[email protected]> wrote: >> >> Hello, >>> >>> I think we need a policy decision on how to add new code to existing >>> projects. Apache Taverna commiters can just merge straight into master >>> but perhaps we should have a policy of using pull requests so that we >>> can review the code first. It might mean there is a slight overhead but >>> maybe long term it means we get better code out of it. Myself and Sagar >>> were just having a chat about this with respect to the TavMob project so >>> it might not be appropriate for every repo. >>> >>> Discuss. >>> >>> Cheers, >>> >>> Ian >>> >>> >>> >>> >>
