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

[Georg Koppen]

Mike Perry:
> Georg Koppen:
> 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.
>  
>> And most importantly how do we make sure that the functionality of the
>> patches is still the same? I very much fear that subtle rebase problems
>> are carried around (see the potential DNS leakage that occurred during
>> the last rebase) making us think everything is fine where in reality
>> this is not the case.
> 
> Well, this we should keep track of via unit tests as best we can.

Yes, although that is currently hard as we are breaking a bunch of unit
tests with our patches (hence there is a lot of noise) and we don't have
good coverage of our own features (e.g. we can't test whether the DNS
patch is properly applied).

> But you're right, there is a danger that a mis-application could happen.
> We probably should not treat auto-rebased patches that claim to succeed
> as the actual final versions. We should instead reapply them fresh
> from the official versions in our repo.

Sounds good to me.

> Manually updated patches we can perhaps mark differently in the repo.

Yes.

>> Thus, I am currently not convinced this is a good idea at all.
>> Definitely not until we sort out how this should work in practice.
> 
> The benefit is the ability to make more active use of Mozilla's testing
> infrastructure, and especially the early notice property. Even if many
> patches end up discarded, we'll at least know that we have a lot of work
> ahead of us for the next rebase cycle, and that we should plan for that
> earlier.
> 
> We'll also get early notice if a feature change causes a subtle
> compatibility issue with our patches due to unit test failures, which
> may be even more valuable.

Those are good points and I agree that this is really worth the setup of
an auto-rebase script (+ a little overhead managing the results). I was
just afraid that we might want to keep up with rebasing broken patches
against mozilla-central all the time and that this effort might be
wasting our resources. Gald this was a misunderstanding.

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20141106/bd8a5549/attachment.sig>