On 6/9/20 9:29 AM, Don Zickus wrote: > 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! > I like the idea. I think it's more in-line with what we're supposed to be doing with a git forge. P. > 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
