From: Damien R. <dr...@ma...> - 2014-01-13 23:41:17
|
On 13 January 2014 11:33, Robert Munteanu <rob...@gm...> wrote: > I think that code reviews are very important, and that Github is a > very good way of doing that right now. +1 I see absolutely no reason to even consider moving away or using anything other than Github for now. However, I would like to clarify the development process, and if possible for the whole team to agree on it. I believe Victor's approach of using pull requests for significant issues and/or new features is excellent, and we should continue doing that. On the other hand, I am concerned that with recent ones [1] we are kind of moving away from our core business which is developing an issue tracker - IMO we should be discussing the issues / features *within our own tool*, and only switch Github for the actual code review as it's more adapted to it. I would like to propose the following high-level process: 1. open issue in mantis 2. write to mailing list to inform other dev's to look at it 3. hold the discussion within the mantis issue as much as possible. If discussion takes place in ML, add a (gmane) link to issue 4. implement solution, submit pull request, add link to it in Mantis and notify mailing list that PR is ready for review 5. team reviews/tests/comments 6. rework as needed 7. merge/close There should be a sufficient delay to allow for reviews/comments before merging (say, 1 week) - today's examples [1] went in a bit fast in my opinion (and probably Paul's too). Finally, we should allow for a "fast track" process for minor changes, improvements and most bug fixes, which should go in as a direct commit, to avoid unnecessary admin overhead. Thoughts ? D |