On Mon, Jun 08, 2020 at 03:10:15PM -0400, Prarit Bhargava wrote: > On 6/8/20 2:58 PM, Jeremy Cline wrote: > > Hey folks, > > > > Seeing the merge window configs rolling in along with people starting to > > open GitLab merge requests rather than exclusively emailing patches, I > > have a suggestion to make everyone's lives a bit easier, especially with > > the configurations: > > > > Start making use of the "developer" role[0] in GitLab. I recommend > > reading over the permissions to get an idea of what's allowed, but the > > short of it is developers can't push to protected branches, so can't > > accidentally (or maliciously) change any of the important branches in > > the repository, but they *can* modify non-protected branches like the > > config branches[1], apply labels, and so on. > > > > Rather than having a script set the configs, then someone review them, > > > ^^^ I think this first step is important. It makes it so I don't have to look > at the CONFIGs myself. Is it possible to have the script set the config, then > have me checkout the branch, change it myself, then push? > Yes, sorry it wasn't clear. I think the workflow should be 1. Scripts make all the config merge requests for you. 2. As a reviewer, when a setting does not match your expectation do something like: a. git checkout -t upstream/configs/2020-06-08/drivers/usb b. vim redhat/configs/... c. git add -A d. git commit --amend # add a note about why it's being changed e. git push -f 3. Ack the merge request. - Jeremy > > > ask the maintainer to change it, then review it again, then have the > > maintainer merge it, you can just check out the config branch for the > > merge request, change it yourself, push it, and mark it ready (or get > > more reviews) for merging. This cuts down on a lot of back and forth so > > it'll save everyone time. > > > > [0] https://gitlab.com/help/user/permissions > > [1] https://gitlab.com/cki-project/kernel-ark/-/branches/all?utf8=%E2%9C%93&search=configs%2F > > > > - Jeremy > > _______________________________________________ > > kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx > > > _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
