[00:09] Would anyone else find http://paste.ubuntu.com/991587/ useful? Should I send that to launchpad-dev? [00:09] My bzrlib is rusty; it probably shows. [00:10] cjwatson: perhaps a useful thing to stick in lp-dev-utils ? [00:11] Yeah, perhaps I should just send an MP there ... [00:25] wgrant: the sharingdetails page for ~launchpad-security timeout cold at around 6s on qas since it is displaying ~750 bugs and that page doesn't have batching. the slowest query is the bugtask privacy filter with all those ORs, plus there's some slowish python to assemble the results. given this level of sharing will be going away and it runs ok on qas after a refresh or two, i think we can leave it go for now. the page bulk [00:25] loads all data and query count is minimal [00:25] wallyworld_: OOPS ID? [00:26] don't have one anymore since i refresh the page with ++profile++ and it went away [00:27] https://code.launchpad.net/~cjwatson/lp-dev-utils/loc-delta/+merge/106080 [00:28] wallyworld_: Can you use ++oops++ to grab one? [00:28] Want to see the query and just how slow it is. [00:29] wgrant: OOPS-3ce9cad8e944ce915a7b4b967eeed405 [00:29] query is the standard bug task id search [00:30] about 1300ms [00:30] that's the slowest one [00:36] StevenK: does your current work add an info_type parameter to makeBranch() in factory? [00:45] wallyworld_: That query is 40ms hot on DF. I wonder if qastaging is just cold. [00:46] wgrant: could be. there's a lot of OR's in there. the page on qas now takes around 5s to load which is pushing the friendship a bit. but it's rendering 750 entries [00:47] and since we do not expect to see that many shared artifacts moving forward, i think it's ok [00:47] or we need to add batching [00:47] We probably will need to add batching, but we'll see. [00:47] the core issue with regard to the number and type of queries has been addressed [00:48] let's see what happens on prod [00:50] wallyworld_: It does, yes. [00:51] StevenK: what's the eta? i may have to put a branch up for review a bit later and then merge yours in before i land [00:54] wallyworld_: I have a bunch of test failures to sort out. [00:54] ok [01:02] wallyworld_: Ahhh [01:02] wallyworld_: There's so many disjunctions that the planner gets confused. [01:03] would IN be better? [01:03] wallyworld_: With <100 it's OK, but with 700 it spends a second planning and gives up. [01:03] wallyworld_: So an IN is much better for huge stuff like this :( [01:03] wgrant: i f*cking told you! [01:03] You didn't say there were 770 of them :P [01:03] i said there were "lots" [01:03] :-P [01:03] I thought we were dealing with sensible batches! [01:04] to quote you, "but this is launchpad" [01:04] Anyway, should be easy enough to convince that function to use is_in instead. [01:04] i'll spin up a followup branch a bit later [01:04] wgrant: i could just replace the OR with IN in all cases [01:04] You'll need to special-case for when the PK is a single column. [01:04] But it's like 2 lines. [01:05] Since technically it can be used for composite keys now too [01:05] Although you could just assert in that case :) [01:05] Since it's unlikely we'll ever want it to. [01:06] comp._relation.get_where_for_local(value) [01:06] for value in search_value.query_values]) [01:06] get_where_for_local can technically return more than a simple equality. [01:06] You should probably assert that it returns a simple equality. [01:06] ok, will look into doing that [01:06] will finish what i'm on first [01:07] Sure [01:08] loc - http://www.ohloh.net/p/launchpad [01:08] _dbify_value and _dbify_column in lp.services.database.bulk show some of the Storm molestation you might desire. [02:10] * wgrant needs a reviewer for https://code.launchpad.net/~wgrant/launchpad/what-the-distromirror/+merge/106086 at some point (non-urgent now) [02:18] wallyworld_: +

Everyone can see this information.

[02:18] Isn't that too hardcoded? [02:18] huh? that's template which is replaced [02:19] By JavaScript. [02:19] like we do for the rest of our TAL [02:19] yes [02:19] + This report contains information [02:19] + [02:19] +

Everyone can see this information.

[02:19] The information_type title will be replaced if it's non-public, but the description will not. [02:19] (before the JS loads) [02:20] hmmm. i think you are right [02:20] i should fix that [02:21] grumble. too many branches open [02:23] Sounds like an error message from Perforce. [02:26] * cjwatson eyes his branch to allow granting per-pocket upload permissions. It's passing tests. I'm not sure I quite believe it can be this easy. [02:27] cjwatson: It's very easy. [02:27] Queue perms are a bit harder. [02:28] But not by much. [02:28] I wonder if this would allow nuking ubuntu-security as a celebrity. (Probably not quite since (a) they have to move over to copyPackage and (b) I have to figure out how to save them from having to manually approve all their copies.) [02:29] That was the plan. [02:29] It's only a celebrity so they can have launchpad.Append on the primary archive, to use syncSource. [02:29] Oh and copyPackage probably needs to learn how to do the librarian republishing dance. [02:29] It should already do that. [02:30] But that needs testing. [02:30] OK, that helps. [02:30] It's in the core copy infrastructure these days. [02:30] Modulo lies about the db revision, does http://paste.ubuntu.com/991705/ look plausible? I'm concerned that the constraint modification there is wrong, but there's no MODIFY CONSTRAINT in pg. [02:31] cjwatson: Seems sort of reasonable, unless you want universe queue admins. [02:31] In which case you want component+pocket. [02:32] s/queue admins/SRU admins/ [02:32] I don't. [02:33] cjwatson: COMMENTs are usually added to database/schema/comments.sql [02:33] I was more concerned whether DROP/ADD CONSTRAINT was remotely sane. [02:33] cjwatson: That's fine, the table is small. [02:33] $ grep COMMENT database/schema/patch-2209-* | wc -l [02:33] 12 [02:33] cjwatson: It's a problem on large tables until PG 9.2 [02:33] StevenK: It can be either now [02:33] Bleh [02:33] cjwatson: grep -c ? :-) [02:33] picky picky [02:33] Haha [02:34] Anyway, no, that's a per-file count [02:35] Well, in that case does anyone fancy allocating me a DB patch number for this? I need sleep shortly but I could get at least the DB side of this going. [02:35] wgrant: the librarian privacy bits only seem to be driven from UnembargoPackage, looking at packagecopier.py [02:36] cjwatson: I'll grab a patch number. [02:36] UnembargoSecurityPackage that is [02:37] cjwatson: You're missing a crucial piece of information. [02:37] cjwatson: Launchpad is not sensible. [02:37] scripts.packagecopier is also called by model.queue [02:37] When realising copies. [02:37] cjwatson: You can also look at lp:~launchpad/+junk/dbpatches and ask someone to allocate you a patch number you pick. [02:37] Ah, but PCJs skip that :( [02:37] bigjools: !!! [02:38] what [02:38] DDs left us with four inconsistent copiers and it makes me sad. [02:38] Ah, I missed the call in realiseUpload [02:39] cjwatson: That's how syncSource works. [02:39] When it sees there are private files it produces a delayed copy. [02:39] Which is actually a PackageUpload. [02:39] The direct/delayed copy nomenclature refuses to fit into my head for some reason. [02:39] cjwatson: 2209-18-1 [02:39] Though I can see how it makes sense. [02:39] Can we destroy delayed copies yet? [02:39] It doesn't make sense. [02:40] StevenK: No, mostly because of this particular thing. [02:40] wgrant: I'm adding a column, is that allowed to be -1? [02:40] wgrant: Yes. :-( [02:40] cjwatson: Yeah, the notes on -0 have been a lie since October. [02:40] cjwatson: All patches are equal. [02:40] And none are more equal than others. [02:41] I've been rather confused, since the last time I asked for a patch number for ADD COLUMN lifeless allocated me a -0, and I figured he knew what he was doing. [02:41] When was that? [02:41] He probably just opted to start a new series. [02:42] 2012-05-08 [02:42] Not specifically for a -0 [02:42] 2209-18-0 cjwatson Add packageset.score. [02:42] 'cause I deploy -1 patches that add and drop tables and columns all the time. [02:42] Heh, 19-0 is already wgrant's. [02:52] we're at +4K over 5 months now, thats much better [02:53] +45K for the same period a year earliy [02:54] A fair bit of that will go away with the next DB refresh, too. [02:56] \o/ [02:56] the encouraging thing is that its a whole OOM [02:56] vs say 75% [02:56] which would have a different and sadder explanation [02:57] cjwatson: are you also in perth this weke ? [02:57] lifeless: No, just insomniac [02:57] Is there some kind of event in Perth then? [03:04] that is particularly insomniac at 4am [03:18] wgrant: the storm NEWS file seems out of date. the one in our lpwithnodatetime fork i mean. do we not need to update that if we package a release? [03:19] We don't ever actually release, we just package snapshots. [03:19] I think it's up to date... [03:19] wallyworld_: Why are you patching Storm? [03:20] to make get_where_for_local work more efficiently and to handle single values and lists [03:20] so we don't have to construct an Or expr manually in the calling code [03:21] or worry about single or composite keys [03:21] so it reduces down to one line in the calling code [03:21] the work is done, i just need to package [03:21] Mmm, I'd just do it in our tree. There's already a couple of functions that poke the necessary bits. None of this is exposed in Storm's public API [03:21] Ah [03:22] What's the diff? [03:25] wgrant: a bit easier to read a straight cut and paste https://pastebin.canonical.com/66227/ [03:27] wallyworld_: Won't that break if I have a composite primary key and say "Foo.bar == (Bar.pk1, Bar.pk2)"? [03:27] Which IIRC works now [03:29] hmm. might do. i'm not 100% familiar with how == is parsed [03:29] i could add logic to handle that [03:30] i was going to run the storm tests to see what broke [03:30] I would just add a separate function [03:30] Well, method if you want it in Storm itself. [03:30] Rather than overloading the existing one [03:30] When it can probably already take an iterable. [03:31] the implementation uses things like self.local_keys which are internal so i think i'd prefer it to be in storm. but we could do it in our tree if we wanted [03:32] Sometimes there's little choice but to poke in the internals, because there's no way to access this internally. [03:32] I mean, look at the caller already :) [03:32] comp._relation [03:32] It already touches Storm inappropriately. [03:32] No way to access this *externally*, that is [03:33] we should push as much of this into storm as we can [03:33] the in-tree storm stuff shouldn't be, mostly. [03:33] Sure, but that involves talking to Storm and working out how to expose these private things sensibly. [03:33] ... or switching to SQLAlchemy, but I digress. [03:34] i wish we weren't on a fork of storm [03:34] The fork is very small. [03:34] so if i do this change, do i just push it to our fork, or do i also get it merged into trunk? [03:34] It's just got a couple of lines of Datetime stuff removed, and the With stuff added. [03:34] wallyworld_: Also merge it into trunk. [03:35] We don't want to diverge any further than we have to. [03:35] Which means that if Storm doesn't accept it quickly, I'd keep it in our tree instead. [03:35] Although Storm development has stalled enough that conflict resolution isn't too bad. [03:35] the issue here is that i would be adding a method which is not exposed publically which we are calling [03:36] and so asking for it to be added to trunk would be unusual [03:36] Right. [03:36] Exactly. [03:36] Which is why it shouldn't be in Storm, unless it's part of a larger strategy to expose this stuff. [03:36] i really don't want to go down that path right now [03:36] Which is why I did bulk.create()'s stuff in LP, not Storm. [03:37] i might stick it with the rest of our storm stuff [03:37] There's no reason to do that. [03:37] hide it under the carpet [03:37] All it does is make things more awkward. [03:37] The stuff in there is only there because it has to be in core, or monkeypatching everywhere. [03:37] _get_where_for_local_many can easily be implemented as an isolated function in our codebase. [03:37] well the alternative is to continue divirging our fork [03:38] 13:37:06 < wallyworld_> i might stick it with the rest of our storm stuff [03:38] Isn't that what you meant? [03:38] Or you mean in like lp.services.database? That's where I'd put it. [03:38] I thought you meant in the fork :) [03:38] yes, that's what i meant [03:38] lp.services.. [03:38] Right. [03:38] There's already very similar stuff in lp.services.database.bulk [03:38] I use _relation there [03:39] at least then also the reference to _relation is shoved off to a helper [03:39] Precisely. [03:39] (bulk.create() uses it to take objects and Reference columns and work out the relevant underlying columns and values -- exactly what you're doing here) [03:40] ok, will do that. might not get it done before i have to duck out to take the kid to his occupational therapy session. but will get it done today [03:40] :) [03:40] then the performance issue should be fully squashed i hope [03:40] Yup [03:41] Sorry for misleading you, I forgot it was an unbatched page. [03:41] it seems to work on prod now but is sliggish [03:41] sluggish [03:41] Thought we were talking like 75 :) [03:41] Yeah [03:41] 75 what? [03:41] 75 bugs [03:41] Not 770 [03:41] It plans 75 ORs with no trouble at all [03:41] ah, right. no need to apologise. [03:42] and 700+ is way too many anyway. once we get stuff cleaned up, that will surely go away [03:42] once we move to policy grants [03:43] Weeell [03:43] There'll still be some big stuff, probably. [03:44] once we find it, we can add batching :-) [03:44] Heh [03:51] lifeless: It's *so* handy that testr --version or -V don't work. [03:53] And I think testr run --failing is running every test [04:01] StevenK: dpkg -l testrepository [04:50] wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type/+merge/106109 [04:56] Aha, the LoC offenders are revealed! [04:57] Hm? [04:57] Linaro looks to be +3400 in total :( [04:57] Is there a breakdown by squad/person? [05:17] wgrant: information_type is fully populated on production, which means we can depend on it. [05:22] StevenK: Oh, bah, indeed. [05:22] Forgot that. [05:22] StevenK: Does it respect transitively_private? [05:22] I suspect not. [05:22] wgrant: In terms of your other comments, http://pastebin.ubuntu.com/991832/ [05:23] StevenK: You untaught the factory about information_type entirely? [05:23] Hm, so I did. [05:27] Bah, .transistionToInformationType respects the rules in terms of branch policy. :-/ [05:35] packageset.score is a terrible name :( [05:35] wgrant: http://pastebin.ubuntu.com/991845/ [05:41] StevenK: Now the factory won't set information_type if you pass private but not information_type. [05:41] And information_type silently clobbers private. [05:44] And if you pass in information_type=InformationType.EMBARGOEDSECURITY, private=False ? :-) [05:47] StevenK: assert [05:47] Don't just silently clobber. [05:53] wgrant: http://pastebin.ubuntu.com/991859/ [05:54] StevenK: You can't spell specify, and that check doesn't handle the case above. [05:55] Yes it does? [05:55] In [2]: b = factory.makeBranch(information_type=InformationType.EMBARGOEDSECURITY, private=False) [05:55] --------------------------------------------------------------------------- [05:56] AssertionError [05:57] But it doesn't complain with private=True. Strange [05:58] Er, yeah, that's the case it doesn't complain in. [05:58] You want both to default to none. [05:58] And at most one of them to not be none. [06:00] Right, fixed. [06:01] wgrant: Now that we've spent 30 minutes talking about the factory, what was your concern with respecting transitively_private? [06:19] StevenK: eg. transitively_private or private gets set on a stacked-on branch, it won't propagate up. [06:22] wgrant: Yes, I'm not sure what happens in that case. [06:23] I do wonder how many layers of stacked_on we have in prod [06:25] wgrant: Shall I land it, or we can talk it over on the call tomorrow? [06:28] StevenK: You need to investigate and probably test how it interacts with stacking. [06:28] There's not much to discuss yet. [06:38] StevenK: I think 7 is the highest [06:39] anyone looked at http://optimizely.appspot.com/features - specifically whether its js will work if we self host ? [06:42] Does a public branch stacked on a private branch leak any information? Is it possible to retrieve revisions only in the private branch via the public branch? [06:43] no and no [06:43] however, the public branch will be unusable [06:43] ah, thought it was a security issue rather than an its broken issue :) [06:50] stacking: an ancient african word meaning 'we made a mistake here' [07:23] stub: catchup? [07:24] lifeless: sure. let me scare up my mic [07:29] stub: I should be logged into skype; if not tell me here and I'll kill-9it [07:29] lifeless: I don't see you [07:44] stub: grah, yeah its hung === 13WAA2ZBF is now known as wallyworld [07:55] stub: [07:55] http://reorg.projects.postgresql.org/ [07:56] stub: http://pgfoundry.org/projects/reorg/ [07:59] Omg [07:59] CLUSTER, but usable? [07:59] Give me it now [08:02] CLUSTER, but scary [08:07] actually, not that scary. Looks like it creates a holding table, adds triggers to the source table, pours data into the holding table, merges in the delta, swaps holding table into place. [08:08] 'swapping into place' is the scary bit as it modifies the system catalog directly so all the dependencies don't notice the move (foreign key references, views etc.). [08:08] Leading to lovely things like: Bugfix: VIEWs and FUNCTIONs could be corrupted that used a reorganized table which has a dropped column. [08:09] stub: I'm back [08:23] stub: http://www.pretotyping.org/ [08:37] ok, night all [08:44] rick_h_: Oh sigh. I see what was broken in bug 1000282. [08:44] <_mup_> Bug #1000282: Uncaught TypeError on translations series +imports

< https://launchpad.net/bugs/1000282 > [10:10] gmb: Any estimate on https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846 being reviewed? If you can't get around to it today I would like to open it up to another reviewer since it is getting urgent. [10:10] jamestunnicliffe: I'll have an updated patch for you by 1pm. [10:10] gmb: Supurb! [10:10] Apologies for the delay; post-UDS stuff has been eating into my time. [10:11] gmb: superb even :-) [10:11] Oh, I can't see this morning [10:11] Good start to the day! [10:33] StevenK: yea, nothing big. I'm surprised there aren't more of those [10:34] StevenK: at some point I'll get back to that AST branch of the combo.meta that will hopefully not be as fragile with the parsing, which isn't all *that* fragile so far [10:46] cjwatson: Did you have any plans to put your loc script for review? If not, I can have a stab at doing that now. [10:55] anyone else having issues with branches not being scanned? [11:02] jelmer: https://code.launchpad.net/~cjwatson/lp-dev-utils/loc-delta/+merge/106080 (which is awaiting scanning for the latest change that renames it to the slightly more explanatory loc-contributions, c.f. wallyworld_'s comment ...) [11:02] * wallyworld_ has 3 branches which have not been scanned [11:02] all within the last 45 minutes or so [11:03] i tried forcing a rescan and also pushing to a new test branch [11:07] sounds like something to ask ops about, since that roughly coincides with the 9.1 upgrade [11:08] Anyone have thoughts on plausible things I can do with bug 1000570? [11:09] bug 1000570 ? [11:09] bah, botless. it's a column rename, which I think is reasonable; the code change that uses it has just landed but not yet been QAed or deployed [11:10] wondering if there's any more elegant approach than backing out the code change, FDTing a rename, reapplying code with rename [11:10] jamestunnicliffe, Can you tell me how to get something to appear in the work items for a Person in Launchpad.dev so that I can test my solution? [11:10] I just want to verify it before pinging it back to you. [11:11] cjwatson: I guess you could just rename it in python and leave it as is in the db. [11:11] I could, not sure that would please bigjools though :) [11:11] seems like this is probably about the best opportunity to get the naming right, and there isn't a desperate rush to get this deployed [11:12] cjwatson: On the other hand, it's marked low so it might be sensible to just leave the bug open until somebody touches this bit of the code again. [11:12] cjwatson: and renaming the zope bit of it at least means we don't break API users in the future. [11:13] I guess I can ask bigjools what he thinks when he's next online. That was easier before he inconsiderately moved. :-) [11:13] :-) [11:15] I mostly don't want to do renaming work in one direction to find that it's insufficient and it would've been easier to back out [11:15] IYSWIM [11:19] cjwatson: fair enough; indeed best to ask bigjools what he means though, the rest of us can only speculate :) [11:19] https://code.launchpad.net/~cjwatson/launchpad/packageset-score/+merge/105915 has the other half of his comments [11:20] jelmer: did you see my loc merge request above that you were asking about? [11:21] cjwatson: yep, playing with the code atm [12:06] cjwatson: branch scanning seems ok again [12:13] wallyworld_: oh good, thanks [12:14] np [12:17] Can somebody set https://code.launchpad.net/~cjwatson/launchpad/db-pocket-permissions/+merge/106091 [12:17] to Approved so I can land it? Looks like it has sufficient review. [12:18] cjwatson: looking [12:19] cjwatson: can you set a commmit msg please? [12:19] Oh yes, done. Thanks, I'll go ahead and land that now then [12:19] ok === matsubara-afk is now known as matsubara [12:39] gmb, did you manage to get workitems to show up on upcoming work page? [12:40] gmb: Apologies, had a few things to get done over lunch and just missed you. There is a script that didn't make it into trunk to create some users with outstanding work items that I can pastebin you if you want. [12:41] gmb, easiest is to create a blueprint, target it to a milestone (with target date set to a date in nearby future), and then add a few workitems in the workitem box on the BP page (eg. "[gmb] Sing the song of love: TODO") [12:47] gmb: Just tested your version - it works :-) [12:50] jamestunnicliffe, oh, I have a script like that... it does create loads of stuff, and using WI titles from production even [12:50] http://paste.ubuntu.com/992291/ [12:51] salgado: Cool - that is more extensive than the one I have. Thanks! [12:52] np :) [12:59] sinzui: hi, i'm about to go to bed but it appears there's a timeout issue submitting mps (i have one i was hoping for you to review). seems coincident with the postgres upgrade. could you ping someone for me to see what's up? [13:02] wallyworld_: OOPS ID? [13:02] jamestunnicliffe: Okay, so, we need to find something to offset the change with. I'll be looking this afternoon and will try to get this into EC2 for you before my EoD. [13:02] wgrant: no oops is shown, just a simple dialog [13:02] * gmb -> grabbing a late lunch; bbiab. [13:03] gmb: Don't worry about LOC. danilos is going to do a big delete soon. [13:03] jamestunnicliffe, danilos: How soon is "soon"? I'd like to be able to point lifeless at it when he asks me... [13:04] gmb, https://code.launchpad.net/~danilo/launchpad/kill-feedback-requests/+merge/106119 [13:04] gmb, I'd be happy to get a review if that works for you :) [13:04] gmb, (i.e. to make it "sooner" :) [13:13] danilos: Then I'll take a look this afternoon :) [13:13] gmb, thanks [13:15] jamestunnicliffe, I just saw that https://launchpad.net/~linaro/+upcomingwork is broken. maybe you guys know about it already... [13:17] salgado: no, that is new to me. [13:20] salgado: is there backtrace or other info available in a log somewhere that could help me recreate it? I see that the linaro team has no blueprints, but I would hope that condition is already covered by a test. [13:22] jamestunnicliffe, you'll have to ask somebody from the LP team for the backtrace. I don't have the rights to see it anymore [13:23] gmb: Can you get those logs ^^ or pass the request on? [13:25] jamestunnicliffe: There will be something soon; I'm waiting for the OOPS data to sync so I can look at it. [13:25] gmb: Thanks. [13:30] Module lp.registry.browser.person, line 4469, in initialize [13:30] 100.0 * total_done / float(total_items)) [13:30] ZeroDivisionError: float division
[13:30] jamestunnicliffe, salgado: ^^ [13:31] wgrant: Thanks. Should be an easy fix! [13:36] jelmer: Thanks. [13:39] wgrant: anytime [13:39] wgrant: how are reviews generally done these days, are there still on-call reviewers? [13:40] ...why is wgrant still awake? [13:41] jelmer: Yeah, there's an OCR schedule. But it's a bit empty sometimes, since some squads are doing other things. [13:41] mgz: It's not quite midnight :) [13:41] jelmer: https://dev.launchpad.net/ReviewerSchedule [13:41] wgrant: thanks; I'd seen it but was curious if it was still accurate [13:42] It's meant to be. [13:42] I guess I should find myself a new slot. [13:42] mgz: https://dev.launchpad.net/ReviewerSchedule [13:42] And is vaguely. [13:42] jelmer: You may wish to strike out Orange for now [13:42] * czajkowski and wgrant are in competition as to who can stay up the latest [13:45] I'll take Thurs/Europe === jelmer changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer | Firefighting: - | Critical bugs: 3.47*10^2 [13:46] Thanks :) [14:06] * jelmer heads out for belated lunch and to get a new headset [14:06] if you want to test it when you get back I brought mine into town :) === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer, jcsackett | Firefighting: - | Critical bugs: 3.47*10^2 [14:31] jcsackett: any idea how you add content to the download section of a project page ? [14:34] czajkowski: i *think* your project needs to have a release, and on the release page there should be an "add download" button. but that information may be outdated. [14:34] sinzui: can you confirm/correct that? ^ [14:34] mgz: feel like doing some headset testing? [14:36] mumblin' it up now [14:37] jcsackett: thanks [14:42] czajkowski: you're welcome. hope i'm right. :-P [14:42]