On Wed, Oct 19, 2016 at 1:26 PM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > On Wed, 19 Oct 2016, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote: >>> On Tue, 18 Oct 2016, Petri Latvala <petri.latvala@xxxxxxxxx> wrote: >>> > The current contributing docs for IGT state: >>> > >>> > << >>> > There is no formal review requirement and regular contributors with >>> > commit access can push patches right after submitting them to the >>> > mailing lists. But invasive changes, new helper libraries and >>> > contributions from newcomers should go through a proper review to >>> > ensure overall consistency in the codebase. >>> >>> >>> > >>> > >>> > While not requiring reviews or acks has definitely increased the >>> > speed of development, I feel the time for slowing down a bit has >>> > come. >>> >>> Agreed. (Though a more rigorous review requirement doesn't necessarily >>> slow things down in the big picture.) >>> >>> > At the very least I would like to see all commits have a visit to the >>> > mailing list before pushing, as the current docs already ask for. The >>> > "right after" part would be changed to a $period of quarantine, maybe >>> > 24 hours? >>> >>> Sounds good to me. >> >> We've already had this, and people stopped bothering. What will be >> different this time around? I feel a bit like we do need to be a bit more >> formal here, to really make this stick ... >> >> Also, who's going to be the annoying maintainer who reminds everyone every >> time they break the rules? It'll take some serious effort here to get >> folks off their well-trodded paths onto a new one I think. > > What's your concrete proposal? 1. Bring up the topic. 2. Discuss it to death until suitable rough consensus emerges. 3. Roll out new rules and have a semi-evil maintainer (I can help with that) enforce them. I think anything up to full review starndards like we have them for the kernel (for all of igt, for simplicity) should be on the table, and would in my opinion be an adequate choice. Personally I'm leaning more towards the process-heavy side. Replied to Paulo with more of my reasons for that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
