On 5/13/20 11:54 AM, Don Zickus wrote: > On Wed, May 13, 2020 at 10:21:31AM -0500, Justin Forbes wrote: >> On Wed, May 13, 2020 at 10:13 AM Prarit Bhargava <prarit@xxxxxxxxxx> wrote: >>> >>> On 5/13/20 10:31 AM, Don Zickus wrote: >>>> On Wed, May 13, 2020 at 07:22:45AM -0400, Prarit Bhargava wrote: >>>>> On 5/13/20 3:50 AM, Jiri Benc wrote: >>>>>> On Tue, 12 May 2020 20:19:09 -0400, Prarit Bhargava wrote: >>>>>>> My patch in merge request 354 changes the names of makefile targets from rh-* to >>>>>>> dist-* >>>>>> >>>>>> I haven't seen that patch on kernel@xxxxxxxxxxxxxxxxxxxxxxx. What's >>>>>> going on? >>>> >>>> The piece of the puzzle you are probably missing is: >>>> https://gitlab.com/cki-project/kernel-ark-ci >>>> >>> >>> Thanks. That's what I was looking for. >>> >>>> which holds the CI scripts. It is in a separate repo for security reasons >>>> (don't want a kernel change to include modifying the CI scripts to falsely >>>> pass something malicious). >>>> >>>> However, that split leads to the scenario you are in, how to update both at >>>> the same time, which we were trying to avoid again for security reasons >>>> (always want to use either a tag or head of master, not a custom branch for >>>> the CI scripts). >>>> >>>> We may have to create a transition patch to handle this. Unfortunately you >>>> hit this scenario sooner than we were expecting to deal with it. :-( >>> >>> Heh :) Of course it's my fault :) :) >>> >>> How about these steps? >>> >>> 1) I patch to add the dist-* targets and keep the old rh-* targets temporarily. >>> This patch will be messy unless someone has some Makefile-fu. >>> 2) I modify the kernel-ark-ci scripts to use the dist-* targets. >>> 3) I patch to remove the old rh-* targets which will result in an overall clean >>> patch. > > That was the approach I was thinking of too. > >>> >>> Would that work for everyone? >>> >> This seems unnecessarily messy. Why not modify the CI scripts to check >> both and as long as at least one of them passes, CI passes? Yup I can do it that way too. > > That is another way. But is there any value to leaving the rh- stuff in the > scripts? Unless we want to preserve legacy like rhel-7/8. I've been wondering the same thing. I think moving forward is the best approach here. I'll modify the CI scripts to do the right thing, then submit an updated patch (jcline's documentation patches were merged and also now need updating). P. > > I don't mind either way. I would like to preserve the idea that for > security reasons the code and the ci rules are split and updated > asynchronously. I think both approaches respect that idea. > > Now ARK/Fedora CI scripts don't really necessitate a split other than the > branching scheme we use. But when CentOS-stream ramps up later this year, > more rules and resources get involved and the security from the separation > becomes stronger. So practicing now helps test out a solution. > > Hopefully that makes sense! > > Cheers, > Don > _______________________________________________ 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
