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&a...
>>>
>>> - Jeremy
>>> _______________________________________________
>>> kernel mailing list -- kernel(a)lists.fedoraproject.org
>>> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>>> 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@lists.fedoraproject.org
>>>
>>
> _______________________________________________
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org