On Thu, 2020-05-14 at 14:30 +0200, Ondřej Lysoněk wrote: > I was originally excited about source-git, however currently I don't see > an approach to source-git that would work for me and I don't think I'd > use it if it became available. And frankly, I think I wouldn't want > other people using it either because it would make understanding their > packages hard. So, another way that could work, with minimal tooling is that we keep the master branch strictly mirroring whatever upstream branch we follow, and then for each fedora release you have a fedora branch where you add the downstream stuff (spec file, patches, etc..). Whenever you want to bring in a new upstream release you would update the master tree to the release as tagged in the upstream master branch, then you branch off a new fedora branch, say fedora33, and then you cherry-pick on top of it whatever donwstream patches you had in the fedora32 branch. The downside of this is that you cannot rebase mid-release. But then you can always cherry-pick patches from a rebase master or from upstream if you want. And the branching, including cherry-picking of downstream patches can be done automatically for the most part. Some issues we normally have can also be handled with some discipline: - upstream has code we cannot ship - upstream does not use git - other issues preventing mirroring For all of these what we do is just use tarballs to create a diff from current master and then do megacommits with the diff on the master branch, and use the fedora branches just for the downstream patches and auto-cherry-picking. Ideally the tarballs are referenced somehow in the master commit via sha256 ids so that you can reconstruct exactly what was layered on top. Those tarballs could also still be stored in the lookaside as a audit trail as well if preferred. The critical thing is how to ensure the master branch is sane, or alternatively how to enable tooling that can switch around the master branch should surgery be required such that the previous one is preserved as a historical branch. (for example if upstream force pushes, we still should have an audited command that saves the previous master as a branch and then allows a rebase). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
