[tbb-dev] Nightly rebase experiment proposal

[Matthew Finkel]

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.
> > 
> > [1]: https://en.wikipedia.org/wiki/Quilt_(software)
> 
> 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