On Thu, Sep 13, 2018 at 04:42:02PM +0300, Jani Nikula wrote: > On Thu, 13 Sep 2018, Daniel Stone <[email protected]> wrote: > > Hey Ville, > > > > On Thu, 13 Sep 2018 at 11:52, Ville Syrjälä > > <[email protected]> wrote: > >> On Thu, Sep 13, 2018 at 11:31:31AM +0100, Daniel Stone wrote: > >> > On Thu, 13 Sep 2018 at 09:54, Jani Nikula <[email protected]> > >> > wrote:> > > 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 ";)" :) > > > > It's more of an answer than it deserved! Thanks. > > > >> Helps when answering questions like: > >> - Who might be able review my stuff? > > > > Yeah, having this easily collated is really helpful. Exposing that > > better through the web interface would be nice. The issue I linked to > > in the previous message would probably be a good entry point for > > exploring how to better expose this through the GitLab UI and API. My > > current workflow is to take the commit SHA, go to > > https://gitlab.freedesktop.org/wayland/weston/commit/SHA1, then click > > through the MR. Not the most optimal thing, but compared to however > > long I spent trying to diagnose the bug before giving up and deciding > > I needed to talk to the author, pretty much a drop in the ocean. > > > >> - Who can I blame for a regression/bug? > > > > All the people who didn't review it as well? > > > >> - Who do I need to poke on irc to figure out what is going > >> on when the patch/commit msg are a mess? > > > > This is _definitely_ an earlier failure. > > > >> - How well was this thing actually reviewed? Often somewhat > >> decently approximated by just "who done it?" > > > > I gave up at the point where I realised R-b and A-b threw away tons of > > information. A lot of commit messages carry those tags from me, with > > all the communication around it skipped. Stuff like 'this seems > > correct to me and builds but I don't understand FreeRDP at all', or > > 'this improves things but doesn't fix the root problem for which a lot > > more work is needed, but we'll take this minimal fix before the > > release', or whatever. I found that I was spending half my time > > digging through mail archives anyway to find out what the person > > actually said, and what their reservations (if any) were. Quite a few > > times I found comments to the effect of 'this is fine, but the obvious > > follow-on work to fix the underlying issue is a/b/c/d', which would be > > the real answer to my question. And despite however many years of > > mutt, I still find it way quicker to click through the full review > > history through the web MR interface than scanning through all the > > mails. But again, that's me and my projects: YMMV. > > > >> 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. > > > > Thinking out loud, I wonder if the `glim` tool couldn't take all the > > MR review notes with a certain string in them (or just all the > > top-level notes) and attach them with git notes? > > The primary question is how valuable we think the metadata is. That > defines where it should be stored. > > For example, I think the Reviewed-by/Acked-by tags are important enough > to warrant storing them in the commit message, which is the primary > place for commit metadata. > > The trouble with storing metadata in a gitlab instance is that it's > centralized as opposed to the decentralized nature of git > itself. Perhaps there are ways to extract the data using their APIs, but > I presume you can't just git clone the data. Running your own gitlab > instance is of course better in this regard than having all the eggs in > one giant shared basket run by a corporation, but it's still > centralized. > > Arguably reviews on mailing lists are also decentralized metadata, but > it's difficult to argue that would be convenient, at least not if you > don't have the messages you want in your local mail store.
Wild idea: Feed the mailing lists into a public git repo? Not sure how crazy that would be. -- Ville Syrjälä Intel _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
