[tbb-dev] auto-rebasing tor-browser patches on gecko-dev master

[Nicolas Vigier]

On Wed, 05 Nov 2014, Mike Perry wrote:

> Georg Koppen:
> > Nicolas Vigier:
> > > Hello,
> > > 
> > > A few days ago on #tor-dev:
> > > 
> > > 01:20 < mikeperry> arthuredelstein,boklm: I'm going into mozilla next
> > >       wednesday, and I suspect they're going to want to make progress
> > >       on getting our branch running in their testing infrastructure..
> > >       a thought occurrs: what if we were to make an auto-rebasing script
> > >       that periodically tries to rebase our patches on to master from
> > >       https://github.com/mozilla/gecko-dev? then we'd not only have early
> > >       warning if they break our new tests, but also when our patches 
> > >       begin 
> > > 01:21 < mikeperry> it may mean more work in terms of constantly fixing
> > >       broken patches though..
> > > 
> > > 
> > > I think I can do something to try to automatically rebase our patches
> > > on gecko-dev master, build and run the tests every night, then send an
> > > email if the rebase failed, the build failed, or a test that was
> > > successful the previous day failed.
> > > 
> > > Sometimes the auto-rebasing will fail. Maybe we can have a 'nightly'
> > > or 'master' branch where we push manually rebased patches when
> > > auto-rebasing failed ?
> > > 
> > > I don't know how often the auto-rebasing will fail, and how much work it
> > > will be to manually fix it though.
> > > 
> > > Does it look like a good idea ?
> > 
> > I think before we start with auto-rebasing at all someone should rebase
> > our patches to mozilla-central once as probably a lot of them are
> > failing if we would start with the auto-rebasing right away which would
> > lead to quite some noise we could avoid. Additionally, there are
> > probably patches that need to get rewritten to a great deal (the image
> > cache part comes to mind here).
> > 
> > This is probably already involving quite some work. Then we should come
> > up with a plan on what to do with broken patches. Do we fix them ad hoc
> > or just once every week or...? Who is going to do that? What means
> > "fixed" here at all? Just a successful manual rebasing or does the code
> > need to be compiling as well at least? If so on which platforms? Who is
> > organizing that?
> 
> Well what I said immediately after those two lines that Boklm pasted was
> that we would store conflicts (as full versions of failed patches) in a
> directory in the repo. In this way, we at least get some advanced notice
> of conflicts, even if we don't have the resources to keep them up to
> date continuously.

Trying to see how it would work:

- we tell the rebasing script the latest tor-browser branch (currently
  tor-browser-31.2.0esr-4.5-1), and its esr branch (currently esr31)
- the script gets the list of patches between tor-browser-31.2.0esr-4.5-1
  and its esr31 ancestor, and try to rebase them on gecko-dev master
- each time there is a conflict when trying to rebase a patch, the
  script adds it to a list of failed patches and skip it

This gives us a list of conflicting patches, and a tree that we can
build to run unit tests or submit to Mozilla's testing infrastructure.

After that, we'll want to manually fix conflict on some of those
patches (or fix mis-application on some others), and store them somewhere
where they will be used instead of the corresponding patches from
tor-browser-31.2.0esr-4.5-1 during the next rebasing process.

I'm not sure where we want to store those manually rebased patches.
Maybe in a specific branch on our repo ? The rebasing script could then
look at the list of patches in this branch before starting the rebasing
process, and then during the rebasing process, if a commit it needs to
rebase has the same subject as one from the "manually-rebased" branch,
it uses the commit from that branch instead.

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