[tbb-dev] Nightly rebase experiment proposal

[Nicolas Vigier]

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:

    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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20191003/d676c255/attachment.sig>