Re: [OS-BUILD PATCHv2] Use upstream/master for merge-base with fallback to master
From: Herton R. Krzesinski on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_546096447 I'm ok keeping the upstream remote for now (short term solution). We can think more and do further changes if we find a better way to handle it. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2] Use upstream/master for merge-base with fallback to master
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_546051611 When you create a fork on gitlab, it should automatically keep it in sync with the project that you sync from, which means origin/master doesn't really go out of date any more than os-build would, and a git pull of origin/master should be the same as a pull on upstream/master if you configured kernel-ark as upstream. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2] Use upstream/master for merge-base with fallback to master
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545998171 @hertonrk-rh - see my above answer to @jmflinuxtx. I have pondered on/off the last few months about how to eliminate the whole 'merge-base' selection as I don't like it and requires git history to run CI (which increases time and uses network bandwidth which isn't always free). I don't have a good answer yet as each attempted solution uncovers more ugly 'master' dependencies and more hacks. :-( And yes, using the 'marker' file was going to be my hard-coded 'merge-base' answer. So I am stuck with moving forward today. My main motivation is to update the docs in !772 but that requires handling the 'upstream' fallout. If I thought I could remove 'merge-base' in a reasonable way, I would go that way instead. But I am struggling to implement something that works. Again I am stuck: short term fix or long term fix. Thoughts? Help? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv4 0/2] Combine duplicate configs across ark and fedora into common
On Mon, Apr 05, 2021 at 11:35:13PM +0200, Paul Bolle wrote: > Hi Don, > > Don Zickus (via Email Bridge) schreef op ma 05-04-2021 om 21:27 [+]: > > Also ran some bash scripts to find another 60 or so duplicates. > > Lazy question (I had trouble skimming the diffs): what actually do you mean > with "duplicates"? Sorry I rushed the commit message. To me, duplicates meant that same config setting in fedora and (common or ark). The idea was to reduce the clutter so that a change in common could be reflected in fedora if it made sense. While Fedora does enable modules, there are lots of core config settings where Justin makes a best effort attempt to set for Fedora. Having a RH employee with expertise provide a detailed explaination for setting those configs in the common area, allows Justin to make a more informed decision about keeping the same setting for Fedora or overriding it with something more appropriate for the project. Hope that helps! Cheers, Don ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure