On Thu, Sep 13, 2018 at 10:54 AM, 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: >>> On Wed, Sep 12, 2018 at 1:34 PM Lucas De Marchi >>> <[email protected]> wrote: >>>> - What should we do regarding the a-b, r-b? Is gitlab going to add those >>>> automatically? >> >> No automation, and right now I'd suggest we squash them in and update >> the merge request. We definitely need to squash them in for the >> kernel, so this is also one of those thing I'd want to look into >> automating. >> >>>> I would not check the 2 boxes to disallow direct pushes until those are >>>> figured out. >>> >>> 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. > > For submitting patches and merging them I can live with having to point > and click on a web site. > > Both of those seem like something that can be automated too. > > But by far the biggest change that is being proposed here between the > lines is moving code review to a gitlab web site, in a one-size-fits-all > model. I could no longer choose and use the tools I prefer for code > review. Tools that I can and have customized for my needs and > preferences. I could no longer review code using the same tools I use to > read and write code (as well as email, and pretty much everything > else). That would be a severe performance hit for me. > > Perhaps I could tolerate that for maintainer-tools, but I won't endorse > gitlab based reviews for any kernel work. > > With that, I think the question should be how we adapt gitlab to our > needs, not how we adapt our needs to gitlab. How do we preserve email > based review while trying to get as much of the benefits of gitlab as > possible? And shouldn't the trials of (at least some of the) smaller > projects such as maintainer-tools be taking that into account, instead > of test driving something that won't fly in kernel?
"How to do review?" Is one of the things I want to figure out. One of the things we _need_ to figure out, before we can roll this out more widely. Dogfooding seems like a good way to go about that. There's also a mail gateway somewhere, which I haven't really tried yet at all (also I think it's not yet set up). We could also do a middle thing, where we do both (i.e. you can do gitlab merge request, or traditional email). And then see where people gravitate towards. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
