On Mon, Jun 08, 2020 at 03:19:52PM -0400, Jeremy Cline wrote: > 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. Interesting approach. I don't mind asking developers to help reduce the burden on a maintainer. :-) We would have to update the scripts to add those instructions to the commit message. Justin is on vacation next week, I will wait until he comes back to discuss this with him. Thanks! Cheers, Don > > - 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 _______________________________________________ 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
