Re: Streamlining the ARK config process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 9, 2020 at 8:30 AM Don Zickus <dzickus@xxxxxxxxxx> 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.
>

I am certainly in favor of anything that reduces the burden on the
maintainer, but more importantly it leaves a better trail when looking
at the commit history.  Currently if I get a request to change
something, that request is in notes of an MR, not clearly in the
commit itself.

Justin

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




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux