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? BR, Jani. > -Daniel > >> > As for requiring reviews or acks before pushing, how do the developers >> > at large feel about that? Different rules for different parts of IGT? >> > (Benchmarks, tools, tests, CI test sets, lib....) >> >> I think there are two big buckets here: >> >> * Tests in BAT and the BAT set list. I think we need r-b/ack on the >> mailing list on these changes before pushing. (In the long run, I'd >> like to have these go through a CI run with everything else unchanged >> too.) >> >> * Everything else. Other tests and tools. I'd be happy with requiring >> the patches are sent to the list, and either receiving r-b/ack or 24 >> hrs during weekdays without negative feedback. >> >> > The goal with this discussion is to reach a suitable tradeoff between >> > stability from CI point of view and fruitful use of programmer time. >> >> Thanks for starting the discussion. >> >> BR, >> Jani. >> >> >> -- >> Jani Nikula, Intel Open Source Technology Center >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
