On Thu, Oct 03, 2019 at 12:39:59PM +0200, Nicolas Vigier wrote:
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:
[snip]
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.
[snip]
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.
I like the idea of using quilt. I've thought about it (periodically) over the last few months, but I stuggled with the development workflow. I only read Greg's blog post today (unforunately), and his description of `linux-stable-rc` is exactly the problem I imagined. However, maybe this continual-rebasing branch is the trade-off we accept in this process.
I don't want to make development more difficult by requiring someone apply all of our patches on top of mozilla-{central,beta,release} before they begin any actual development. On the other hand, I don't want to maintain two "official" sources of "Tor Browser" (as in, maintain a set of quilt-maintained patches, and a git repo). I would prefer only using quilt, if that was really an option. I think the idea of frequently rebasing the git repo and force-pushing to the public git mirror(s) is a reasonable compromise (while the patch sets are the official sources).
gbp pq looks like a nice improvement around quilt, and I think we should experiment with it, too (thanks intrigeri).
- Matt