On Thu, Sep 13, 2018 at 11:31:31AM +0100, Daniel Stone wrote: > Hi, > > On Thu, 13 Sep 2018 at 09:54, Jani Nikula <[email protected]> wrote: > > On Wed, 12 Sep 2018, Daniel Vetter <[email protected]> wrote: > > > On Wed, Sep 12, 2018 at 7:50 PM, Sean Paul <[email protected]> wrote: > > >> Given the size of this repo and the number of contributors, I'm not > > >> convinced either of these should be blockers. We should avoid merge > > >> commits since the volume is low enough that having to rebase should > > >> be quite rare. Reviews and acks will be recorded in the merge request, > > >> which is easily accessed from the UI. > > > > > > Not sure recording review&acks on the merge request is going to fly > > > for kernel. And that's kinda what I want to test-drive here, in 1st > > > gear :-) > > > > If the acks and reviews aren't recorded in git log for each commit, they > > don't exist. > > To be fair, given that DRM is about the only subsystem doing it, does > recording it in a fixed format in the commit matter? ;)
Answering despite the ";)" :) Helps when answering questions like: - Who might be able review my stuff? - Who can I blame for a regression/bug? - Who do I need to poke on irc to figure out what is going on when the patch/commit msg are a mess? - How well was this thing actually reviewed? Often somewhat decently approximated by just "who done it?" I suppose if there would a be tool to suck those out from gitlab when you need them given a specific commit it might work out. Although that doesn't sound quite as efficient as just having the information there in the commit msgs. -- Ville Syrjälä Intel _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
