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&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