From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/995#note_545993958 @jmflinuxtx - yeah I am trying to address the documentation with !772 and @hadess1 had some questions about the workflow with regards to an origin tree and an upstream tree. So that MR's changes will tie directly to what we agree here with origin and upstream. I agree origin/master should still work. The concern is over time, the fork'd master generally is never updated (or rarely updated), so origin/master is quickly outdated. Most users who fork will/should update their 'upstream' tree to get the latest master. At least that appears to be the general habit of developers in the new RHEL workflow (whether good or bad). I am not tied to a particular name or process and will happily update the docs to reflect whatever we agree on. I just want to handle the situation where some of us clone origin and git-push to it. And then handle other users who can not git-push to origin. Either we give them developer rights to push directly to origin or provide a way for them to contribute if we do not want to give them Developer rights (or do not trust them yet). Using 'upstream' is one example for an alternate way to contribute. Thoughts? Also happy to combine this work with your -stable changes as they overlap with regards to which $MASTER to use. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
