[00:00] "bzr diff --diff-options='-C 10' -rancestor:../devel" seems to work fine. [00:00] wgrant: Ooh, thanks! [00:01] sinzui: Great, thanks! [00:04] sinzui: How do I manually position that sprite (it always sticks it in the top right of the container right)? [00:04] huwshimi: you cannot :( [00:04] sinzui: oh [00:05] however maybe we can change the generation rules to create more white space to offset when the colour starts [00:05] sinzui: so should I create an html element to contain the sprite and position that? [00:05] That will look right, but I think we have a line-height issue [00:06] sinzui: This seems like a pretty fundamental issue with our sprite generator :( [00:06] sinzui: you can't even right/center align or anything then. [00:07] huwshimi: you are over thinking this. We have something that makes the sprite. We have rules in .sprite that does the basic offset. the other items in the css are non-negitiable [00:07] huwshimi: that is because the image is a background [00:08] wgrant: whats up with qas codebrowse? [00:08] lifeless: qas http codehosting is broken. [00:08] * StevenK kills hudson [00:08] * sinzui looks for the sprite generation rules [00:09] lifeless: I am hoping that codebrowse will magically unbreak once HTTP in general works. [00:09] 301 look [00:09] 301 loop [00:09] Or that buildbot will not explode this time, will update db-stable, and then allow me to QA on staging instead. [00:09] Yes. [00:09] wgrant: is there an RT open ? [00:09] lifeless: No. [00:09] But spm was working on it before. [00:12] win [00:13] oracle kicked kohsuke from the java.net project for hudson [00:13] That's a bit rude [00:13] yes [00:14] http://java.net/projects/hudson/lists/dev/archive/2011-02/message/15 [00:18] lifeless: To be frank, I'm disgusted at ORA for their handling of this [00:18] Oh, awesome. [00:19] * StevenK is fixing Hudson to actually run a build [00:19] Which wasn't helped by the cloud controller going off into lala-land [00:21] StevenK: yeah, ditto [00:22] Is anyone not disgusted about Oracle's handling of anything recently? [00:23] oracle? [00:26] Haha [00:27] StevenK: want to review https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement/+merge/48254 ? [00:27] flacoste: still around ? [00:32] wgrant, lifeless: Reviewed [00:32] StevenK: you still need a mentor right ? [00:32] lifeless: Right [00:32] thumper: ^ :) [00:33] ah? [00:33] thumper: you're StevenK's mentor, right ? [00:33] yup [00:33] * thumper looks [00:33] StevenK: do you realise that wallyworld_ is waiting on a review from you? [00:34] Oh, argh [00:34] * StevenK looks at that [00:34] Got distracted by Hudson being broken [00:41] StevenK: :( zip is awesome [00:42] wallyworld_: Ugh, 960 lines. [00:42] wgrant: Why :( ? [00:43] StevenK: it's mostly tests etc [00:43] StevenK: You said you hadn't seen it before. [00:43] wgrant: No, I use map() for that sort of thing, but zip() looks good. [00:44] The map() in Perl is scarier [00:46] StevenK: thanks for review. You completely happy the code used to find the related package branches is ok? [00:46] wallyworld_: Yes, it looks fine, providing your tests exercise it all. [00:47] StevenK, wgrant: commented [00:47] StevenK: i think they do but i'm not 100% familiar with that part of the domain model so am a little nervous that i have missed something [00:50] thumper: I initially added the class unconditionally, but it seems redundant, may be a lie (when text_to_html is inserted in the middle of some other text), and breaks dozens of tests. [00:51] wgrant: hmm... [00:51] wgrant: I'm flexible on the conditionalness of the css class, but I think the code needs tweaks [00:51] wgrant: it is unfortunate that it breaks so many tests [00:51] And yes, your proposal is much easier to understand. The current one evolved from when it was unconditional. [00:52] wgrant, StevenK, lifeless: well, at least oracle's behaviour means that everyone should immediately jump ship to jenkins on github, i guess? [00:53] That'd be nice. [00:53] mwhudson: its not that simple ;) [00:53] lifeless: It isn't? [00:53] mwhudson: sonatype are following oracle; various corporate users have expressed concerns about the discussion with *their* mgmt [00:54] urgh [00:54] well, let's hope that Oracle keeps blundering around destroying things. [00:56] TBH, it seems more like controlled destruction rather than blundering [00:56] They surely can't want the entire community to evacuate. [00:58] They haven't been entirely clear and open about what they do want, either. [00:58] they have [00:58] Last I read, they were still discussing, have things moved on? [00:59] they want the trademark, the core infrastructure libraries changed to ones with contributor agreements, compulsory contributor agreements for plugin authors [00:59] strict process [00:59] And this while they swear they don't have any customers using Hudson? [01:00] the have support customers of hudson inherited from sun; they ak'd that. they don't have a hudson /product/ that they sell [01:04] rockstar: ping [01:05] or anyone else who is familiar with the lazr-js tests [01:10] thumper: when you have a spare moment, can you rubber stamp (or not) that related bracnhes mp? i'm still a little nervous that the algorithm used to find the related branches is correct. it looks ok but... [01:11] wallyworld_: ok [01:27] thumper: Seems like moveBranch is used by branch.setOwner, which will rename if necessary, but it wants a user to do the move as, and I don't feel comfortable just randomly grabbing at an admin [01:27] StevenK: ah... whut? [01:28] StevenK: perhaps we should talk this through [01:28] thumper: Sure [01:28] StevenK: but give me a few minutes [02:11] * wallyworld_ thinks it's interesting that +linkbug on a branch page pops up an ajax form whereas +linkbug on an answer page goes to a separate page. would have expected some consistency there [02:16] wgrant: hey, can I throw a bug your way? https://bugs.launchpad.net/launchpad-buildd/+bug/693524 [02:16] <_mup_> Bug #693524: java failure in recipe builders < https://launchpad.net/bugs/693524 > [02:16] wgrant: I was discussing with flacoste and we agreed it is an operational thing [02:16] wgrant: seems like an intermittent failure of some kind [02:16] wgrant: most likely needs input from lamont [02:22] mwhudson: hi, got a minute? [02:22] thumper: sure [02:24] mwhudson: otp now [02:25] poolie: https://launchpad.net/~ubuntu-branches/+members#active [02:26] yes, i see [02:26] mwhudson: mumble or skype? [02:26] thumper: skype is usually more reliable [02:26] ok [02:27] logging in now [02:27] thumper: i can hear you! [02:27] let me play with alsamixer [02:28] mwhudson: what? no pulse? [02:28] thumper: can you hear me now? [02:31] Hard / Soft Page ID [02:31] 832 / 8921 Archive:+index [02:33] lifeless: We have a winner. [02:33] \i/ [02:33] 13:31:23 < lifeless> Hard / Soft Page ID [02:33] 13:31:24 < lifeless> 832 / 8921 Archive:+index [02:33] 13:33:12 < wgrant> lifeless: We have a winner. [02:36] lifeless: Do we have a pattern for caching SQLMultipleJoins? [02:37] gimme a sec [02:38] I think I can probably turn it into a cachedproperty that returns a list. But I am hoping there is a less bad way that I've missed. [02:39] Sorry was otp [02:39] whats the join you're looking at ? [02:40] wgrant: are you talking about caching the collection on a domain object ? [02:41] lifeless: BinaryPackageRelease.files [02:41] I need to prepopulate and cache that. [02:41] Apart from iteration its users are fortunately few. [02:41] wgrant: the simplest answer is don't use the .files attributes [02:42] lifeless: Replacing it with what? [02:42] wgrant: actually, lets step back [02:42] wgrant: whats the service point you're optimising ? [02:42] lifeless: CopyChecker.checkCopy and PublishingSet.copyBinariesTo [02:43] This particular case applies to both, but mostly the former right now. [02:43] they are internal apis [02:43] Ah. [02:43] Archive:+copy-packages and Archive.syncSource. [02:43] whats the *service* point: LP API or pageid [02:43] ok [02:43] Both. [02:43] do they deal with > 1 BinaryPackageRelease ? [02:44] Yes. [02:45] wgrant: ok, so we need to eager load for some N b-p-r the releated binary package files [02:45] wgrant: we're going to want decorated result set's pre_iter_hook for this [02:46] wgrant: in terms of exposing it, cached property is completely correct [02:46] wgrant: If I was doing it I would: [02:46] changes 'files = SQLM...' [02:46] to '_files = SQLM...' [02:46] create a cachedproperty for files which returns self._files [02:46] - not listified = [02:47] and then eager load from where needed [02:47] wgrant: do you see why not listified ? [02:48] lifeless: No. [02:48] its a collection; adding to a list wouldn't DTRT [02:48] Right, but we never add to the collection, except with addFile. [02:48] And the collection will be lazy. [02:48] so perhaps that doesn't matter [02:48] So we have to return a list. [02:49] the service pointyou're optimising won't ever access the SQMLMultipleJoin anyway [02:49] because you're going to be eager loading [02:49] So it is going to sometimes return a list and sometimes a ResultSet? [02:50] Er, SQLMultipleJoin, not ResultSet, but same thing. [02:50] not the same, though similar ;) [02:50] yes, thats correct, because result sets don't cache [02:50] Same problems. [02:50] eg. .count() works on one, but not the other. [02:51] SQLMultipleJoin is SQLObjectResultSet [02:51] (oh how I wish we used SQLAlchemy...) [02:51] wgrant: do you need to do counts() ? [02:51] lifeless: Some places do. [02:51] But I will make them use len. [02:51] wgrant: in which case, back to my prior statement - stop using .files [02:51] Because files will be a list very shortly. [02:52] create a new thing - e.g. getFiles, have *that* always return a list and cache, and eager load it for the service point. [02:52] or, migrate completely to lists if you like [02:52] That seems like overkill for something that is an iteration-only attribute anyway. [02:52] Right. [02:52] wgrant: well, its not iteration only from what you say ;) [02:52] Or we could use SQLAlchemy :D [02:52] iteration and counting, no mutation or indexing, then. [02:54] shiny http://www.thinq.co.uk/2011/2/1/new-it-announces-dreamplug-arm-box/ [02:54] Is Sheeva ARMv7? [02:55] I thought it was Kirkwood. [02:56] [15:16:22] wgrant: I was discussing with flacoste and we agreed it is an operational thing [02:56] [15:16:36] wgrant: seems like an intermittent failure of some kind [02:56] [15:16:42] wgrant: most likely needs input from lamont [02:56] wgrant: not sure if you saw those [02:57] thumper: I didn't. I don't even know what they reference. [02:57] wgrant: sorry, I missed the earlier bits [02:57] Sorry, my connection was out for 5 minutes or so. [02:57] [15:16:07] wgrant: hey, can I throw a bug your way? https://bugs.launchpad.net/launchpad-buildd/+bug/693524 [02:57] <_mup_> Bug #693524: java failure in recipe builders < https://launchpad.net/bugs/693524 > [02:57] Ah, right, that bug. [02:57] Yay. [02:57] bigjools poked lamont about it a couple of days back, IIRC. [02:57] He said he didn't know of anything. [02:58] hmm... [02:58] we really need some trigram support in the namecache [02:58] It sounds like it's running out of RAM, though. [02:59] lifeless: namecache? targetnamecache, or is there another one? [02:59] only one [03:00] its a little noddy; we might be better off to move the target dereferences into it [03:01] thumper: Hmmm, that's really odd. [03:03] It's definitely a lamont sort of thing, unless someone else can hijack a virt builder and check it out. [03:03] * wgrant wanders out for a while. [03:07] There is trigram support in postgresql-contrib. I've not bothered with it yet as it was part of the whole search story and unclear what our goal is. [03:10] 'for sale in the UK' but the power plug in the picture is US. That might be my future media centre. [03:10] stub: I think broadly we want to bring lucene/lucandra in [03:10] stub: but we need stopgaps along the way [03:10] stub: are you able to look at the scripts that restore [qa]staging ? [03:11] whats up with them? [03:11] qastaging's database is a few months out of date [03:12] stub: as StevenK says, the qastaging db, while its schema is ok, has very stale data. [03:13] We don't have a script to rebuild it? [03:14] There seems to be a restore_launchpad_qa.sh in ~postgres/scripts on sourcherry [03:15] So I guess a losa needs to run that. [03:17] stub: hmm, I thought the plan was: [03:17] - restore to a temp db; clone that for staging (and patch); clone it for qastaging [03:17] so both would restore at the same time. [03:17] stub: could you run 'explain analyze select count(*) from bug join bugtask on bugtask.bug=bug.id where ftq('kpassgen') @@ BugTask.fti; [03:17] ' [03:17] on the prod instances for me ? [03:19] http://paste.ubuntu.com/561236/ [03:20] stub: thanks; thats very interesting [03:21] Anyone available to review a branch of mine? [03:21] apparently our full text index is sufficiently poor that a seqscan of all bugtasks is better than an index scan [03:21] for a search returning one row [03:23] StevenK: shoot [03:23] lifeless: https://code.launchpad.net/~stevenk/launchpad/merge-recipes-during-merge/+merge/48264 [03:23] wgrant: want some review practice? [03:23] I can redo the 'build _new databases' and 'swap into place' processes, which is in database/replication/Makefile in the lp tree. The losa scripts will then need tweaking. [03:23] stub: if you have the time, this would be nice to sort out [03:25] I'll try and get something to test at the start of the next cycle. If we are desperate this cycle, we should rebuild with the existing process. [03:29] I'm not sure now why this speeds things up. [03:30] We only rebuild staging once per week at the moment because it is replicated, and the bulk of the time is building the replica. [03:31] And rebuilding qastaging is faster with the existing process (restore dump, swap into place) than (restore dump, copy to new db, swap into place) [03:32] stub: not desparate [03:32] stub: whatever is faster is fine; I had an incomplete understanding [03:32] It will speed things up if we go to Slony-I 2.0, because then we can use a new feature to build two replicated databases quickly. [03:32] stub: the goal is weekly qastaging rebuilds [03:32] stub: question for you on slony 1.x - with 2 slaves, are transactions done in parallel on the slaves? [03:32] (restore a db, clone it, set up replication but tell slony the data is already good so no need to copy it from master -> slave) [03:33] e.g. N time on master and then ~N on each slave, but the slaves don't wait for each other [03:33] Its done in parallel. [03:33] cool [03:33] stub: in which case I think you confused yourself analysing the time for julians type change patch [03:33] Otherwise replication would stop if any one slave fell over or was down. [03:34] Oh... DDL. [03:34] stub: its the same, surely? [03:34] I think it is done master then all slaves in parallel. What is the formula on the wiki? [03:34] stub: not sure; just saw you add another 50% for the second slave in backlog here the other day [03:35] We tested this and worked out the correct formula for DDL, but now I'm fuzzy on the actual empirical results :)( [03:37] stub: uhm [03:37] stub: help me out here; where is the bugtask.fti index [03:38] stub: I see a gist index for bug.fti, but none for bugtask.fti [03:38] For DDL, it could be either. Depends if Slony's EXECUTE SCRIPT runs the script on all nodes one in series, or all nodes in parallel, or creates an event that goes through the normal replication channels, or runs on the master then creates an event so changes propagate to the slaves per normal replication. [03:38] Think the latter. [03:40] Whoops. I guess we lost the index somewhere. They get created by fti.py. [03:40] Perhaps when experimenting with GIN indexes a few years ago? [03:41] Or fti.py might be broken and the index never got created... [03:42] stub: could you create it on qastaging? [03:42] I'm looking at this 7 second query, and 4 seconds of it seems to be text search [03:45] wallyworld_: whats the bug you're working on that bug 711619 is a dup of ? [03:45] <_mup_> Bug #711619: "Merged at revision" in merge proposal pages doesn't link to the revision < https://launchpad.net/bugs/711619 > [03:46] lifeless: its building now [03:46] stub: wicked, thanks. [03:46] lifeless: i'll look [03:46] wallyworld_: perhaps its not a dup; but it seemed to be offhand to me. [03:49] lifeless: Created [03:49] stub: \o/ [03:49] lifeless: i'm landing bug 334336 [03:49] <_mup_> Bug #334336: Show which branch and bug are related to a revision

< https://launchpad.net/bugs/334336 > [03:50] i'm only doing the extended reision listing on the branch index page though [03:50] the merge proposal page is unchanged [03:50] stub: drops the queries I was trying from 800ms to 50ms [03:51] I'm creating the indexes on production (Bug #711632) [03:51] <_mup_> Bug #711632: BugTask.fti missing an index < https://launchpad.net/bugs/711632 > [03:51] stub: thanks! [03:51] -> Seq Scan on bugtask (cost=0.00..52921.26 rows=158774 width=152) (actual time=0.022..550.938 rows=184186 loops=1) [03:51] Filter: ((distribution = 1) AND ((status = 10) OR ((date_incomplete IS NOT NULL) AND (status = 15)) OR (status = 15) OR (status = 20) OR (status = 21) OR (status = 22) OR (status = 25))) [03:52] >< [03:52] * wallyworld_ hates qastaging timing out all the time :-( [03:53] lifeless: if you want to see what it looks like: https://code.qastaging.launchpad.net/~bzr-pqm/bzr/bzr.dev [03:53] bear in mind most bzr revs have linked branches [03:53] many other series don't and only one or two revs will have those links [03:54] hi ian [03:54] hi poolie [03:54] wallyworld_, oh, wow, that is nice [03:55] makes it easier to get to stuff, that's why i picked up that branch during the bug jam - thought it would add value [03:55] had to out it on hold while i was on leave, but landing now :-) [03:55] it would be nice if the bug icon was colored and the status/importance was shown [03:55] s/branch/bug [03:55] i guess if this is already landed that could be done as a follow on [03:56] hmmm. i just use the default rendering. [03:56] perhaps if a bug is fixed it is always grey [03:56] but i could show the importance [03:57] wallyworld_: That requires identifying the task. [03:57] MPs and branches already have code to do that, though. [03:57] that would have to be another branch though, since this one is already qa-ok [03:57] wallyworld_: ui thought; 'with linked bugs' is prose-like, but this isn't prose [03:58] wallyworld_: just having the indented table of bugs is pretty self explanatory [03:58] poolie: raise a bug if you want anything extra added :-) [03:58] lifeless: i agree now that you point it out :-) [03:58] At least 178 queries/external actions issued in 2.18 seconds [03:58] lifeless: You might want to add input to https://code.edge.launchpad.net/~gary/launchpad/bug548-db/+merge/48263 , which is adding a boolean flag to Person. [03:58] thats reasonably snappy; could reduce the qquery count a little [03:58] wallyworld_: nice work [03:59] stub: is there a better place to add it? [03:59] ta [04:00] stub: ah, I see [04:00] lifeless: New table maybe. At the moment, personal settings like this just got tacked onto Person (like the existing verbose_bugnotifications flag) [04:00] and mailing list subscription policies [04:03] commented [04:04] * wallyworld_ wonders why fields on ajax popup render in different order to when a separate page is rendered for the no script usage? [04:04] lifeless: O hai, did my review fall off your radar? [04:04] StevenK: I'm mentoring wgrant [04:04] StevenK: and hes awol (lunch I guess) [04:04] Oh, sorry, forgot about that. [04:04] * wgrant looks. [04:05] * StevenK reads scrollback [04:05] Oh, now I see the prod. Sorry. [04:05] lifeless: As a 'yes, this is a good idea' or 'no, this idea sucks' re bug 711636 [04:05] <_mup_> Bug #711636: Support linking bugs directly from the MP < https://launchpad.net/bugs/711636 > [04:07] StevenK: nice idea [04:08] wallyworld_, what tags should such a bug have? [04:09] perhaps just ui? [04:09] i don't think it's confusing-ui [04:09] no, i was wondering if it was 'code' or something [04:09] but perhaps that's irrelevant now [04:09] that's what i was thinking [04:10] poolie: could you also add a comment to remove the "with linked bugs" prose pretty please as per a comment a few lines back :-) [04:10] it can be done as the one branch then [04:10] sure [04:10] thanks [04:10] i agree with that too [04:11] is it just me or is that font especially tiny? [04:11] i made it small (but hopefully readable) to ensure the rev listing didn't require so much page space with all the new info shown [04:12] i can read it ok. do you think it's too small? it passed a proper ui review [04:12] oh ok [04:12] i can _read_ it [04:12] it just kind of jars [04:12] it's something like 50% of the size of the regular body text [04:12] and it's not really fine-print informaiton [04:13] i like it because it still allows you eye to scan the individual revision lines easier [04:13] for instance it's 50% smaller than the copyright notice, and i care much more about the bugs [04:13] well, i just thought i'd mention it [04:13] i can see your point too though [04:13] not a showstopper [04:13] maybe we could let the dust settle so to speak and see if there are many complaints [04:14] easy to change if required [04:14] wallyworld_, what happens if the bug was directly fixed in that revision rather than by a merge? [04:14] it's still shown, but not indented? [04:14] sure [04:14] the bugs which are shown are those linked to the merged branch. so no branch = no bugs [04:15] lifeless: For design, I'm leaning towards PersonSettings and TeamSettings. Columns not filtered on and the appserver doesn't need when dealing with lists of people can be moved into one of those two. So Person.displayname stays, but mail_resumption_date goes to PersonSettings and renewal_policy, mailinglist_* goes to TeamSettings. [04:15] that's the current behaviour [04:15] poolie: perhaps something else to add to your bug report? [04:16] We start getting explicit separation of team/person then too, while keeping Person as PersonOrTeam which has been useful and will be hard to change. [04:18] wallyworld_, https://bugs.launchpad.net/launchpad/+bug/711641 [04:19] <_mup_> Bug #711641: bugs directly fixed in a revision aren't shown in branch view < https://launchpad.net/bugs/711641 > [04:19] lifeless: should we be doing "except Foo, e" or "except Foo as e" ? [04:19] to me that's more of an actual bug (if true) not just a tweak [04:19] poolie: agree. i'll look at it and do a fix sooner rather than later if there's a problem there [04:20] https://bugs.launchpad.net/launchpad/+bug/711643 for the nits [04:20] <_mup_> Bug #711643: tweaks to branch merged-revisions view < https://launchpad.net/bugs/711643 > [04:20] thumper: either [04:20] thanks for adding it though [04:20] poolie: will likely be next week after 11.02 rollout [04:20] thumper: I'd write as e for things which are in lp core; things which bzr may want, for instance, we'll want python 2.4 compat [04:21] poolie: np. spiv was interested as well in this feature i think [04:21] wallyworld_, btw, i'll help you and spm roll out the forking lp-serve changes next week [04:21] it's on the LPS page as an unusual deployment task [04:21] ok [04:21] thumper: No mail from Aaron? [04:22] stub: could you look at my last comment in bug 661988 - is there anything else we can /should do? and would a union like that be useful or nuts. [04:22] <_mup_> Bug #661988: Timeout on Distribution:+bugs search < https://launchpad.net/bugs/661988 > [04:22] StevenK: yes actually [04:22] poolie: thanks. i hadn't yet followed up with that stuff [04:22] StevenK: I'll forward it to you [04:22] stub: lastly, why do we bother having a bugtask fti column at all? [04:22] thumper: Thanks [04:23] lifeless: Full text search on targetnamecache? [04:25] and statusexplanation (dunno why we want to search on that) [04:25] kde-guidance (Ubuntu) | 'back':70C 'bug':9C,45C,53C 'chang':67C 'click':57C 'close':7C 'column':65C 'comment':27C 'current':60C 'describ':23C 'futur':49C 'give':34C 'guidanc':3B 'hesit':42C 'inform':15C,38C 'investig':19C 'kde':2B 'kde-guid':1B 'lack':13C 'miss':37C 'need':17C 'new':72C 'pleas':28C 'previous':26C 'problem':21C 'reopen':29C,51C 'report':10C,46C,54C 'status':61C,64C,69C 'submit':44C 'thank':73C 'ubuntu':4B 'us' [04:25] update-manager-core (Ubuntu) | 'core':4B 'manag':3B 'ubuntu':5B 'updat':2B 'update-manager-cor':1B [04:25] mozilla-firefox (Ubuntu) | 'around':26C 'b':31C 'back':37C 'check':50C 'complet':45C 'disabl':46C 'experi':41C 'firefox':3B 'flash':10C,22C,48C 'flash-play':21C 'float':25C 'folder':30C 'home':29C 'incompat':20C 'inde':8C 'left':58C 'ly':32C 'mozilla':2B 'mozilla-firefox':1B 'ok':5C 'old':16C 'player':23C 'pleas':35C 'plugin':49C,53C 'presum':19C 'problem':42C 'report':36C 'still':24C,40C 'ubuntu':4B [04:27] thumper: is monday a pub hoiday? [04:28] lifeless: do you want it to be? [04:28] would be nice :P [04:28] that it would [04:28] I think if all NZers agree, then it should be [04:28] we only have to convince mwhudson and pjdc [04:28] :) [04:28] waitangi day is feb 6 [04:28] yes [04:28] it is also the weekend [04:28] sadly it is not a holiday [04:29] wallyworld_, oh also https://bugs.launchpad.net/launchpad/+bug/711647 [04:29] <_mup_> Bug #711647: link from branch page to merge proposals