On Tue, 21 Nov 2017, Nicolas Vigier wrote:
This looks like a good plan to me.
If we go with that plan I think we should also check whether a git branch is still the best way to maintain our patches. I have not been thinking about that a lot yet, but maybe an alternative could be to use quilt [1] or some similar tool to manage patch series. So we could store a quilt patch series as a directory somewhere into tor-browser-build.git, which should make it easier to apply our patches on different firefox trees.
On his blog, Greg Kroah-Hartman described his workflow: http://www.kroah.com/log/blog/2019/08/14/patch-workflow-with-mutt-2019/
In the section "Stable patch review and apply" he describes how he uses Quilt for maintaining the stable kernel tree:
The process of reviewing patches for the stable tree is much like the development patch process, but it differs in that I never use ‘git am’ for applying anything.
The stable kernel tree, while under development, is kept as a series of patches that need to be applied to the previous release. This series of patches is maintained by using a tool called (quilt). Quilt is very powerful and handles sets of patches that need to be applied on top of a moving base very easily. The tool was based on a crazy set of shell scripts written by Andrew Morton a long time ago, and is currently maintained by Jean Delvare and has been rewritten in perl to make them more maintainable. It handles thousands of patches easily and quickly and is used by many developers to handle kernel patches for distributions as well as other projects.
I highly recommend it as it allows you to reorder, drop, add in the middle of the series, and manipulate patches in all sorts of ways, as well as create new patches directly. I do this for the stable tree as lots of times we end up dropping patches from the middle of the series when reviewers say they should not be applied, adding new patches where needed as prerequisites of existing patches, and other changes that with git, would require lots of rebasing.
Rebasing a git does not work for when you have developers working “down” from your tree. We usually have the rule with kernel development that if you have a public tree, it never gets rebased otherwise no one can use it for development.
Anyway, the stable patches are kept in a quilt series in a repository that is kept under version control in git (complex, yeah, sorry.) That queue can always be found (here[1]).
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/
I think doing something similar might work for us, and would make it easier to apply our patches on different Mozilla branches.
It would also make it easier to look at the history of our patches. Currently we create a new branch for each Mozilla release, where we rebase our patches, squashing or removing some of them, so looking at the history of a patch is difficult as you have to look at many branches.
Nicolas