Thanks for the explanation. :) On Fri, Nov 4, 2016, 7:59 AM Stian Soiland-Reyes <[email protected]> wrote:
> It's very low tech, subscribe to commits (or look at archive), just look at > quickly at every email and reply (back to dev@) if something is unclear. > Revert git commit if something breaks. > > (But no-one are necessarily "on watch" so commits might go unnoticed.) > > Apache Commons work like that, which is a bit important there as they have > granted all ASF committers write access and the Commons libraries have > hundreds of thousands of users. > > You could also look at the git log locally or at GitHub, but we have many > repositories and a couple of branches. This might be good before a release. > > On 4 Nov 2016 1:39 pm, "Gale Naylor" <[email protected]> wrote: > > > 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 > > > >>> > > > >>> > > > >>> > > > >>> > > > >> > > > > > >
