[00:02] xnox, hi, Did ubuntu-kylin-software-client and ubuntukylin-default-settings get accepted? Maybe I miss something from the queuebot:) [00:02] JackYu: i didn't get email, let me check queue [00:02] sorry, ubuntu-kylin-software-center (not client):( [00:03] JackYu: ubuntu-kylin-software-center is still in the new queue. [00:03] slangasek: sounds good to me! thanks [00:03] xnox, oh, thanks. [00:03] JackYu, xnox: I'm reviewing ubuntu-kylin-software-center now [00:04] JackYu: ubuntukylin-default-settings 1.1.4 is in the arhive since 8th of april [00:04] xnox: yes, but there's one in unapproved that goes in once uksc is accepted [00:04] slangasek, great! It's 8 am here. Our QA team is waiting for the latest ISO:) [00:05] slangasek: ah, yeah i see it now. [00:05] hmm, is archive.ubuntukylin.com:10006 the production port for the service? [00:05] slangasek: queue names like search thing is not substring based search =( [00:05] xnox, slangasek, yep. We will upgrade something in ubuntukylin-default-settings 1.1.5. [00:06] slangasek, yep. [00:06] ok [00:07] my old job only allowed 80, 443 and 22 out =) [00:07] Yeah, that sounds pretty bad for firewalls... [00:07] and 443 had to be ssl traffic, they inspected it. [00:07] wgrant: there's only one firewall that matters for this particular archive, and it's the one at the border ;) [00:07] Heh [00:07] wgrant: it's like kees "ssh over dns queries" backdoor into buildds =) [00:09] xnox: +queue text search is a per-term prefix search, not a full substring search, for performance reasons. [00:09] xnox: was the switch to a native package discussed with upstream? Because upstream did have a tarball release on LP [00:10] slangasek: the upstream had "_2.9.2.orig.tar.gz" and debs uploaded into 2.9.2 release that did not match their trunk branch -> and clearly came from a daily recipe builds that generated the tarball. [00:10] xnox: ah, ok [00:10] xnox: but - you did also discuss this change with upstream, right? :-) [00:10] slangasek: and upstream accepted my merge proposal to switch to native. [00:10] ok good [00:10] slangasek: and i'm upstream committer now as well [00:11] slangasek: i should merge that reviewed branch now =) [00:12] slangasek: done, upstream trunk is tagged 0.2.9.1 and matches the upload. [00:12] xnox: aren't you missing some from __future__ import print_function here? [00:12] I see an awful lot of print->print() changes, but no print_function anywhere [00:12] not a NEWing consideration, but it might be useful if the app doesn't fail immediately with python backtraces [00:14] slangasek: i did not do that. let me check. [00:15] slangasek: yeah i see that introduced / used refactored in a few places. [00:15] xnox: you want to fix/upload? [00:16] slangasek: yeah. [00:17] slangasek: shokingly "pyflakes" doesn't tell me about them. [00:17] otherwise, the package as a whole looks fine, so accepted [00:17] xnox: right, I noticed because it was in the debdiff vs. the previous version [00:17] (that I had been poking at locally) [00:21] slangasek: clearly i didn't manage to generate any exceptions while testing it =) cause they'd crash [00:30] slangasek, xnox, thanks a lot. Would you help to take a look the ubuntukylin-default-settings 1.1.5? [00:35] slangasek: i'm opting in for revert - http://paste.ubuntu.com/7232982/ [00:36] slangasek: adding "from __future__ import print_function" results in invalid syntax errors, as only a handful of print's are functions, the rest are statements. Refactoring everything to print function is a huge diff, better done as part of porting to python3. [00:36] slangasek: and the revert to a consistent print statement is smaller diff. [00:36] and i'd rather have 1 style through all code base. [00:36] xnox: ack [00:38] ./ui/uksc.py:140: undefined name 'data' [00:38] ./backend/search.py:315: undefined name 'get_query_for_pkgnames' [00:38] ./backend/search.py:366: undefined name 'time' [00:38] ./backend/search.py:369: undefined name 'time' [00:38] ./backend/search.py:375: undefined name 'log_traceback' [00:38] ./backend/aptdaemon/dbus_service/apt_dbus_service.py:408: undefined name 'Daemon' [00:38] hm.... [00:39] JackYu: does ubuntukylin-default-settings still need an upload sponsored, too? [00:39] slangasek: i see one in rejected. [00:40] slangasek: also did keyring got sorted out? [00:40] xnox: yes [00:40] hmm, yes, it is in rejected [00:40] slangasek, happyaron uploaded 1.1.5 [00:40] who rejected that? [00:40] oh... [00:40] ok, I'll look - but am on the way to dinner right now, so it'll be a little bit [00:41] JackYu: that's fine, sometimes reviewers stash things into rejected, which are waiting for some other packages to be uploaded. [00:42] xnox, sure. lol. [00:43] slangasek, have dinner first:) I think it's middle night at United States. [00:43] JackYu: usa - west coast is 6 PM =) middle of the night is here in the UK for me - 2AM [00:48] xnox, :) [00:49] JackYu: please review https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/invalid-syntax/+merge/215325 [00:50] JackYu: and please assign / get warnings from https://bugs.launchpad.net/ubuntu-kylin-software-center/+bug/1306313 fixed - i'm not familiar with the code and somebody who understand it better should address those [00:50] Launchpad bug 1306313 in Ubuntu Kylin Software Center "pyflakes serious warnings" [Undecided,New] [00:52] xnox, got it. Thanks. We will review it asap. === jhodapp is now known as jhodapp|afk [04:45] i'll poke ubiquity after i wake up =) [04:59] xnox, good night:) [05:36] slangasek, uh - yes - I did indeed add the breaks/replaces to the wrong package and I did use the wrong version - apologies [05:37] jamespage: no worries. The adjusted version is still waiting in the unapproved queue for a second set of eyes; maybe you'd like to check it over and do some upgrade tests, and if it looks ok I can accept it? [05:56] slangasek, ack - will do. Oddly enought I did upgrade test this - does the fact that its only conffiles moving package make a difference? I def had no problems [05:57] slangasek, either that or my mind is playing tricks on me [05:58] jamespage: well, if you happened to get the packages unpacked in the right order, it would've worked even without the Replaces [05:59] slangasek, the combination with the new conflicts might have done that [06:06] slangasek, certainly looks right - testing now [06:21] jamespage: how's the testing? I'm afraid it's bedtime here [06:28] alangasek, if this is for neutron.. i don't mind taking over. [06:28] err, slangasek ^ [07:28] hello all [07:28] can I have an ETA on when webbrowser-app will leave the unapproved queue? [07:29] Daviey, is slangasek is now eod that would be appreciated [07:34] jamespage: how did the testing go? [07:35] Daviey, +1 [07:35] Daviey, I tested an upgrade from 0ubuntu1 -> 0ubuntu3 with both the vpn and l3 agents installed; upgraded OK - l3 agent bumped off the install (as expected - I installed the vpn-agent) [07:37] jamespage: silly question.. but has upgrade from 12.04 been tested? Essex, and UCA versions? [07:38] Daviey, I've tested the upgrade path via the UCA from folsom->grizzly->havana->icehouse [07:38] Daviey, upgrading straight from essex is hard as the overall architecture of openstack has changed - specifically neutron (grizzly) and cinder (folsom) [07:39] jamespage: if it has to be sequential updates is this documented? [07:39] Daviey, it will be - I'll make sure it gets into the release notes [07:40] Daviey, technically I think nova is the only bit that needs that - its the only project that has rolled up db migrations [07:40] Daviey, we can jump other things directly [07:40] (i can't imagine anyone is still using Essex.. but you never know, right) [07:40] Daviey, you do never know - I triaged a bug report from a 12.04 user who had tried to go essex->havana the other day [07:41] oh. ;) [07:41] Daviey, not in a serious way - they just happened to have nova-common installed from 12.04 at the time [07:42] That makes more sense. [08:04] good morning, i'm pinging about the last webbrowser-app upload in the approval queue; we have (sorry) other webbrowser-app fixes stuck in silos after that [08:05] thanks for your attention if you can rview those this morning [08:10] hey release team ;-) [08:10] xdg-user-dirs and shared-mime-info uploads are translation updates from launchpad (they don't use langpacks) [08:11] those didn't get uploaded yesterday because the DoS/launchpad downtime made I didn't get the exports before my eod [08:16] dbarth: you know we're in final freeze? [08:16] seb128: looking [08:17] Laney, thanks [08:19] Laney: I guess the goal was to open as soon as we can't get things into the release pocket for seeded packages -updates pocket for things seeded in desktop and touch [08:20] that's the plan cjwatson discussed about. However, he talked about Monday [08:20] so unsure for today, but we'll need to find something IMHO [08:21] Laney, didrocks: let me know if we can still land updates today and next week, or if we need another approach for continuing to accumulate fixes for a potential SRU [08:22] dbarth: nothing will change from your POV as long as you do bug fixes [08:22] i totally understand the need to stabilize the distro before the release, just need a direction [08:22] ok [08:22] we just need to find which channel it's going to :p [08:28] I don't know how such redirection works so I'm going to leave things like that for now [08:49] dbarth: erm, why is the source PPA for webbrowser-app showing depwait? [08:49] Ie, build failure [08:50] uh, not sure; let me check with oSoMoN [08:50] Hmm, Arm64, armf, PowerPC and ppc64 [08:51] It doesn't build on those arches [08:51] that’s because oxide itself doesn’t build on those arches [08:51] not armhf [08:51] Not armhf. But yes, that's expected [08:51] I assumed armf at least was a release goal for this stuff? [08:51] Oh yes [08:51] It only needs to build on the arches listed in "rmadison -s trusty -S webbrowser-app" [08:52] ah right, that's the same issue as before [08:53] Right, no worse. My mistake, should have looked closer. [08:58] I think we need to do a block-all in p-m, selectively unblock things that are allowed, and sru-release (or equivalent) anything else [08:59] block-all source rather [09:00] last time round we did that on 2013-10-15 [09:00] so this is a bit earlier, but meh [09:00] block-all source - stuff that are only seeded on touch and for the rest, go on a case by case? (either release or -updates?) [09:00] Could do it for the intersection of touch and , or something [09:00] - being "minus"? [09:01] ^ telepathy-indicator is a small diff that should fix empathy online status in the indicator [09:01] I don't have a mechanism for that, but we can do it manually [09:01] would be nice to get in for release [09:01] and for that matter the touch release team have unblock hint access [09:01] cjwatson: the FFe bug for Touch is a good list of things being "seeded in Touch only" [09:01] I'm happy to unblock on those [09:01] https://code.launchpad.net/~larsu/telepathy-indicator/lp1103438/+merge/215271 is the corresponding merge request [09:01] didrocks: there's no code for "block-all except stuff" [09:01] ah [09:01] and I'm not going to write any now [09:02] so, then, it's only hints [09:02] from the release team? [09:02] "block-all source" applied now, so ~ubuntu-release and ~ubuntu-touch-release should unblock as needed [09:02] yeah [09:02] (in the latter case, for touch-only stuff) [09:02] so I can unblock all packages that are touch-only [09:02] listing them [09:02] yes [09:02] one by one [09:02] ok, I'm using the FFe bug [09:02] well, no, unblocks are versioned [09:02] stop [09:02] ah [09:02] you have to unblock selected uploads [09:02] that's going to be really painful [09:03] deal with it :) [09:03] thanks [09:03] ok, let's say current Touch is finale then [09:03] I wouldn't expect it'll take that long [09:03] the need for any hints will be obvious in excuses [09:03] that's an overreaction [09:04] well, "deal with it" as well [09:04] it's first thing in my morning and I wake up to everyone shouting at me ... [09:05] I would suggest that we can continue to unblock touch stuff pretty freely until Tuesday or Wednesday or so [09:05] cjwatson: I don't think I shouted at you, I just hinted you from that discussion and didn't jump on you on purpose on that one to let you catch up [09:05] my point is that it is not really painful to unblock uploads [09:05] if you don't want to bother I'm happy to [09:06] it's still for each package -> I have to check it's seeded only on touch only [09:06] (you or your team) [09:06] then unblock [09:06] like I say, if you (plural) don't want to bother I'll do it [09:06] it's not a big deal [09:06] or beg the release team beyond upstream [09:06] for get things in [09:06] I would prefer not deal with those and get into -updates if needed [09:07] I would prefer not to use -updates until we need to [09:07] it's harder to track correctness there [09:07] because the only check we have is "valid candidate" in excuses, we won't get the uninstallability check from the output phase [09:08] ok, that's a valid one if that's not supported by p-m [09:08] we have -updates as an escape hatch, and we can use it when things are on both touch and something else and we decide we'd rather not take the risk elsewhere; but it's not a free pass, we don't have as good tools for it [09:08] (unfortunately) [09:08] using it is going to require extra manual checks [09:08] so people shouldn't be labouring under the assumption that it's easier / less work [09:09] cjwatson: the issue is that the "you" plural is singular most of the time as the only one active on the list would be cyphermox, ogra and I [09:09] like I say I have no problem helping out with that [09:09] and I'm sure others could as well [09:10] * ogra_ finds an old hints branch and sees kenvandine in there too [09:10] ogra_: yeah, ken isn't active on that though [09:10] ah, k [09:10] i just saw he has a file in there [09:11] cjwatson: well, seeing the amount of work you have to review unapproved already, I'm unsure the RT will have time to deal with it [09:11] hmpf ... and i seem to never have bzr pulled in that branch [09:11] what was the upstream url for it again ? [09:11] didrocks: based on past experience it's fine [09:11] ogra_: lp:~ubuntu-touch-release/britney/hints-ubuntu-touch you mean? [09:11] thanks ! [09:12] didrocks: also, generally unblocking can be done at the same time as accepting through unapproved, so it doesn't require thinking about it twice [09:12] (IME) [09:12] cjwatson: so, anyway, seems there is no alternative, so I'll list all with versions [09:12] one by one [09:12] cjwatson: I wonder though [09:13] can't I set unblock , then I just amend with a version? [09:13] or that will make the system bugging? [09:13] if you do that right now I believe you'll crash proposed-migration [09:13] ok [09:13] I would like unversioned unblocks to work [09:13] even commented? [09:13] But I'd prefer not to mess with that code a week before release [09:13] I just want to have the list handy [09:13] so that I know if it's touch only or not [09:13] just keep it in your homedir or in some other file in that branch [09:13] proposed-migration only looks at a specific named list of files [09:13] ok, if you think the parser will be at risk [09:14] commented is fine too [09:14] ok, let me create a file in that branch then [09:14] but it'd be clearer for other people if it wasn't in your personal hints file, IMO [09:14] yeah [09:14] like touch-only.list [09:14] yep [09:14] ok, doing this [09:15] i assume i can safely flush the entries from last release from my file in that branch ? [09:15] ogra_: I did for mine some time ago [09:15] I'm seeing if I can quicly extend generate-freeze-block to come up with this list [09:15] Laney: well, I think cjwatson's "don't risk production code" before release makes sense [09:15] generate-freeze-block isn't production code as such [09:16] cjwatson: so, for the webbrowser-app one, this will be reviewed as usual and unblock if RT is happy with it? [09:16] that would be replacing block-all with a gigantic block that affects the whole archive [09:16] or something [09:16] ogra_: yes [09:16] done, thanks [09:16] but you are not afraid with britney crashing with the gigantic block list? [09:16] no [09:16] we use gigantic block lists elsewhere [09:18] sigh, KDE didn't all clear through automatically so we'll have to unblock that [09:18] * cjwatson looks through the ftbfs pile [09:26] Laney: thinking about it, I think we only applied block-all last time once we needed the archive to quiesce for release [09:26] Laney: so maybe your big freeze block approach would in fact be better for this [09:27] not that it isn't helpful for people to remember how to unblock stuff, but :) [09:32] cjwatson: Yeah, I think so [09:33] Trying to get the logic right [09:33] Laney: if you need any help from me, I'm happy to check with you [09:33] I'll share a list when I get one that I think is right [09:34] ok [09:34] It would certainly be nicer to do less work even if it's not too hard :) [09:39] cjwatson: Laney: seems there is again 2 new MPs for webbrowser-app coming which are the same kind of fixes than the one in UNAPPROVED. So that you don't have to review the same package 3 times as upstream planned at first, I asked them to get that in one landing [09:40] so I'm kicking out the current version in UNAPPROVED [09:40] mkay [09:41] didrocks: do you know if qtcreator-plugin-remotelinux got prenewed? [09:41] cjwatson: yeah, I did that [09:41] http://paste.ubuntu.com/7234140/ ? [09:41] (some worth and back and checked that my concerns were fixed in latest versions) [09:41] Packages which are on touch and some other image [09:41] Hopefully [09:41] Laney: looking [09:42] Laney: for actually putting this in p-m, don't we need the list of all packages on any image other than touch? [09:43] Depends what you want to block, I guess [09:43] Laney: so, you are also dealing with build-deps from what I see, right? (like autopilot) [09:44] hrm, how did that get in there? [09:45] It's not there when I run it again ... [09:45] *magic* [09:45] lxc-android-config? [09:45] that looks weird [09:45] oh [09:46] didrocks: yeah, looks ok, accepted (q-p-r) [09:46] that's because I forgot the flag when I ran this [09:46] http://paste.ubuntu.com/7234167/ [09:47] so, yeah, last time round we apparently didn't block anything for final freeze, only in the unseeded freeze right at the end [09:47] so I was thinking the idea was to let touchies carry on as normal ish, blocking their shared things in proposed so that they can be considered as discussed earlier [09:47] cjwatson: thanks! [09:48] it wasn't what I was initially thinking, but it makes sense [09:48] for everything else use the unapproved queue [09:48] then use the block-all source instead at T-2 days as for Saucy [09:48] yep, bit confusing but I can deal with that [09:49] Might be worth a mail [09:50] Laney: this list is what is seeded on touch and desktop it seems? [09:50] not things that are seeded on any flavor (but Touch only)? [09:51] like I would have except to see some unity-lens-* [09:51] or gnome-* [09:51] right [09:51] it's shared touch and other things components [09:52] ok, and so, desktop-only will be blocked by something else? [09:52] (taking ubuntu desktop as an example) [09:52] Laney, I would rather the touchies didnt touch anything on our image now, given it won't be tested before upload [09:52] unapproved [09:52] darkxst: this block catches that [09:53] but really it's mainly about the CI train stuff [09:53] Qt possibly to a lesser extent [09:53] Laney, there is stuff in that list seeded on our images [09:54] darkxst: this is a list to block, not a list to allow [09:54] darkxst: that's good, it's the list of things that will get blocked [09:54] ah, ok [09:54] but the unapproved -> autoaccept already had the interesect of Touch + any other flavor? [09:54] intersect* [09:54] * didrocks is probably silly, but doesn't understand [09:55] auto-accept is: not in a package set, not listed in seeded-in-ubuntu other than ubuntu-touch [09:55] unapproved -> autoaccept was for Touch-only [09:55] yeah [09:55] Is it ok for me to make a upload of parole for a missing recommends? It fixes a high importance bug, and xubuntu (where it's seeded) approves the change [09:55] didrocks: I think the idea is that this allows people to accept touch-related stuff (touch-only or not) into -proposed without having to carefully check whether it affects desktop [09:56] didrocks: and then anything that isn't touch-only out of that, we can have in -proposed in a place where we can then move it to -updates if we need to [09:56] Noskcaj: sounds fine [09:56] cjwatson: ok, this makes sense to me [09:56] it's a bit twisty [09:56] but I think it ultimately makes sense [09:56] right, I get it now [09:56] I think so, if it turns out not to in practice then it's only a text file to edit [09:57] the volume should be low at this point anyway :) [09:57] Laney: the list looks to be the right one to me :) [09:57] Laney: *if* only [09:57] mini troll, sorry [09:57] that Friday feeling [09:58] heh ;) [09:58] seems that some people committed still to features and so, features + stabilization is expected [09:58] (sure, so easy) [09:58] but that's out of my hands as you know… [09:59] Laney: thanks for building that list, after a second look, nothing bleeds through my eyes [09:59] (I thought we stopped shipping zg though= [09:59] * didrocks checks [10:00] It'll be interesting when it comes to trying to release a product on such a fast moving base (especially if the base of that is a development release) [10:00] 'bleeds through my eyes' sounds funny to me - is that a translation of a French expression? [10:00] Laney: yeah, you know how French rules to directly translate expressions :p [10:01] Laney: and +1 on the "it will be interesting" :p [10:01] we still (ship zg-core in touch oh my) [10:02] ok, updated hint pushed [10:02] cool, thanks [10:03] thanks! [10:04] I'm working on clearing out component-mismatches, BTW, it's just fairly slow going [10:05] lots of checking ... [10:05] NBS is clear at last [10:15] what's happening with icedtea-web? [10:20] oSoMoN: you do have a FFe for https://code.launchpad.net/~michael-sheldon/webbrowser-app/file-upload/+merge/212605? [10:20] (I saw you approved it) [10:21] as webbrowser-app is not seeded by Touch-only, it's not in the blanket Touch FFe [10:25] didrocks, I don’t [10:25] didrocks, can you point me to a template FFe so I can file one? [10:29] Hi release team! There's a low-risk packaging fix upload of libaccounts-qt in -proposed - it fixes a packaging conflict - could anyone push it further to the archive? [10:29] I'm going to be polling excuses for blocked packages and I expect others will too [10:30] oSoMoN: https://wiki.ubuntu.com/FreezeExceptionProcess [10:30] didrocks, thanks [10:30] yw [10:32] sil2100: Mirv: we need this FFe to ba acked before publishing the webbrowser-app silo ^ [10:33] didrocks: ok, will remember that, let me put up a comment [10:33] Laney: thanks o/ [10:38] right [10:41] So, looks like mochikit still needs an MIR, or python3-paste needs neutering? [10:41] Everything else wanting main promotion looks like fallout from bugs or FTBFS packages. [10:43] didrocks, here goes the FFe: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528 , let me know if additional information is required [10:43] Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New] [10:45] oSoMoN: adding it to the landing [10:46] didrocks, oh wait, I just realized that this MR (file-upload) introduces a runtime dep that’s in universe: qtdeclarative5-ubuntu-content0.1 [10:47] oSoMoN: yeah, you're going to fix/amend this? [10:48] didrocks, well I’m not really sure how to fix that, I would have expected qtdeclarative5-ubuntu-content0.1 to be in main… :/ [10:49] I could make it a suggests instead of a direct dep, that would work because on desktop it’s not used and on devices the content hub is guaranteed to be there [10:49] oSoMoN: that would be better [10:49] but I’d like to get some input from Elleo and Ken as to why it’s not in main [10:49] oSoMoN: I guess it's too late for a MIR on content-hub [10:49] sounds way too late indeed [10:50] oSoMoN: maybe prepare both? [10:50] downgrade to suggest/rebuild [10:50] ensure it's still fine on desktop without it [10:51] didrocks, another option is to simply remove the dependency from debian/control: since it’s only loaded dynamically at run time and only on devices where the content hub is guaranteed to be installed, it won’t make a difference [10:52] (instead of a suggests which wouldn’t make sense on desktop anyway) [10:52] oSoMoN: fine with me as well, your pick [10:52] didrocks, I’ll go for that one [10:52] ok, great, thanks! [10:55] oSoMoN: while you are doing that, let's see if you get an answer soon on your FFe :) [10:56] didrocks, I [10:56] cjwatson: Want to make some seed vs. demote decision on the 300 new grub binaries? [10:56] didrocks, I’ve pinged Elleo who’s the owner of the branch to do the change, if he doesn’t answer in the next 10 min I’ll branch and submit a MR myself, to speed things up [10:57] infinity: yeah, I was going to seed those [10:57] somewhere [10:57] I'll do it after coffee :) [11:01] cjwatson: Oh, err, you're not doing overrides right now, are you? [11:01] (Before I hit enter on this gtk-sharp and jquery* demotion and double-override the world...) [11:02] * infinity takes the selince as a no. [11:03] infinity: not right now [11:08] didrocks, Elleo acked the request, he’s working on the change as we speak [11:08] grea t;) [11:09] Alright, knocked out maybe 10 or 15 lines from c-m, time for breakfast while that settles. [11:11] Laney, ^ unity [11:11] I see it [11:11] ;-) [11:19] Laney, thanks ;-) [11:20] yw === jhodapp|afk is now known as jhodapp [11:52] infinity: Hey, do you have a view on bug 1305839? [11:52] Launchpad bug 1305839 in maas (Ubuntu) "FFe: Support for Third Party Driver Installation" [Critical,New] https://launchpad.net/bugs/1305839 [11:53] infinity: did you 'unofficially approved the FFe'? [11:57] didrocks, dependency issue fixed for the file-upload branch of webbrowser-app [11:57] oSoMoN: great, keep us posted on the FFe status! [11:59] didrocks, it hasn’t been updated yet, who can I ping to get it reviewed? [11:59] oSoMoN: normally, the release team pick up the FFe list. I think enough of them are in the channel to notice that discussion, or you can click on the team you subscribe and try to ping them :) [12:00]