[tbb-dev] Tor Browser uplift tracker

Georg Koppen gk at torproject.org
Mon Jan 29 11:47:00 UTC 2018


Arthur D. Edelstein:
> Hi Tor Browser devs,
> 
> I've been working on uplift this week and I have updated the uplift
> tracker table at
> https://torpat.ch .

Wow, thanks. FWIW something like that did I have in mind when asking
about a list of patches and how they map to tickets etc. Although, this
is way fancier than I imagined. Very helpful!

I did not look at the priorities set right now.

Mcs/brade: I might have got some of your update or profile dir related
patches wrong. Please have a look especially at those if you have some time.

> There are bugzilla bugs for most of our eligible patches, but there
> are still about 15 "untriaged" patches in gray, because I couldn't be
> sure if they were appropriate to uplift. If you have time to have a
> look at the untriaged ones you are familiar with and let me know if
> you think any are available for uplift, I would be grateful. My goal
> is to mark all patches either red, yellow, or green so that no
> untriaged patches remain.

Some comments regarding the patches after I went over the whole list:

1) According to Richard the patch for #23016 does not need uplift.

2) I am not sure whether we want to uplift #21431. I think we can leave
it as "no uplift" for now.

3) f4dd994 could be "no uplift" right now.

5) #21907: "no uplift". There won't be an option to build with GTK2
anymore for ESR 60.

6) #21849: "no uplift" for now I think. See: bugs 1183318 and 1188657
for the Mozilla discussion.

7) Not sure if "uplifted" means "we are done here". If so, the patch for
#5741 is in the wrong category. See:
https://trac.torproject.org/projects/tor/ticket/21611#comment:5

8) #14970: "no uplift".

9) 5e2ac8a is already uplifted.

10) #13252: I am inclined to say "no uplift" as this patch only exists
because we need to ship an own bundle (which we don't want to do if we
are done with our Firefox fork).

11) #13379: probably "no uplift" (for now at least). At any rate we'd
need to investigate first what we still need to carry over to ESR 60
here, given that https://bugzilla.mozilla.org/show_bug.cgi?id=1105689
got fixed.

12) #21724: "no uplift", the reasoning is the same as in 10).

13) #18912: seems worth trying to uplift.

14) #19121: it seems this is WONTFIX for Mozilla right now? I guess we
keep it and make our argument later again? Or we argue along the lines
of 10) and bite the bullet.

15) #18900: "uplift" according to
https://bugzilla.mozilla.org/show_bug.cgi?id=1159090#c4 I guess.

16) #11641: "no uplift", the reasoning is the same as in 10).

17) #9173: I am not sure but after skimming over it, it seems like "no
uplift" with reasoning like in 10)?

18) #18995: Seems worth uplifting to me (in case Mozilla does not have
similar test already).

19) #3875: "no uplift" right now. I am more and more convinced we need a
new patch for this idea (if at all) as the current one seems to be
wrong. See: #19910 and above all dcf's amazing
https://trac.torproject.org/projects/tor/ticket/24432#comment:19.

20) #5282: "no uplift". The whole pipelining code is gone and Mike is
fine having our patch removed in that wake, too.

21) #16488: "no uplift" yet at least. We don't even have a proper patch
ready right now: see #22564 for instance.

Do all new patches somehow block the META Tor uplift bug? (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1432905? Shouldn't that
block 1433504 at least?)

Georg

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


More information about the tbb-dev mailing list