RTC for large changes and CTR for maintenance sounds good. I'm curious - What is the process for CTR with the @commits list?
On Fri, Nov 4, 2016, 5:31 AM Stian Soiland-Reyes <[email protected]> wrote: > 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 > >>> > >>> > >>> > >>> > >> >
