[01:50] wgrant: after the is merged, will it run, or is there a flag to set? [01:52] blr: garbo jobs are run automatically. [01:53] blr: Some have the ability to be enabled or disabled by feature flag, but they must implement that themselves. [01:54] wgrant: ok, just uncertain about the performance profile of this job, but I see there are others that operate over the entire product collection. [01:56] blr: It is not problematic. We have garbo jobs running over collections several orders of magnitude larger. [01:58] ok good to know :) [02:40] blr: Care to land that branch so we can deploy this afternoon? [02:40] (if you tried before it probably got caught in the testfix) [02:40] wgrant: sure, was just waiting for buildbot [02:47] blr: Thanks. [06:48] wgrant: webhooks; nice. [06:57] lifeless: That's the plan. [06:58] For Git pushes initially, but obviously once we have the infrastructure we'll look at expanding it. [06:58] Also investigating a general event system. [07:16] Conflict adding file lib/lp/services/webhooks.moved.moved.moved.moved. Moved existing file to lib/lp/services/webhooks.moved.moved.moved.moved.moved. [07:19] Oh bzr <3 [08:14] wgrant: you have one already - the public wabbit server [08:14] wgrant: (aren't webhooks just a particular client of that ?) [08:15] lifeless: txlongpoll would be a client of the RabbitMQ-based event system. [08:15] lifeless: txlongpoll would need a complete redesign to be the centre of it all. [08:16] sure [08:16] be nice to have it outside the squishy core is all ;) [08:16] (and the idea would be that events would also be persisted, such that activity streams can be presented, and eg. bug notifications can be responses to events) [08:17] Oh, certainly. I consider this webhook implementation a production-ready prototype that will hopefully be obsoleted by an event system designed with things we've learned from this. [08:17] wgrant: sounds like apache thingy. Uhm, linkedin's thing [08:17] distributed persistent log [08:17] Kafka? [08:17] yes [17:46] Hey all, I'm lurking here for some months so it's time to introduce myself: [17:46] I'm Riccardo, 22 years old Computer Science (2nd year) student from Italy. [17:46] I contribute to Ubuntu for 3 years, beginning with my Loco and then writing code for Ubuntu Touch (core apps and webbrowser, mainly). [17:46] I'm quite involved (I also joined two sprints) and I have a lot of fun. Since the start of the year I'm thinking to contribute to LP, a project I really like (definitely the best bug tracker on the internet). [17:46] The only problem: I don't know Python :-P [17:46] But since April I work for a startup and now they want I learn Python, so I'm studyng on Coursera and CodeAcademy and I already completed the basic tutorial on the Python website. [17:46] So, what's better way to learn something new than contributing to an opensource project? [17:46] (Sorry for the wall of text, now questions are coming) [17:47] Do you think I could be useful if do some patches, starting from bitesize bugs? [17:47] Probably at start I'll do silly patches and I'll have some silly questions. [17:47] Sure, we aren't short of them [17:47] So, do you think I could be useful? Let me be clear: I want to help, not to be a burden for the project. [17:47] cjwatson, great :-) Do you think with a good commitment I can contribute to LP or it's better to start from something simpler? [17:47] Starting with that attitude is already a pretty good sign. [17:48] IMO the biggest skill (other than Python, general programming, etc.) you need to contribute effectively to LP is the ability to navigate a large codebase and not be scared by it. [17:49] It's pretty regularly laid out, so once you get a feel for it it isn't nearly as hard to find things as the raw size of the tree would suggest. [17:49] let's try then - I did a couple of patches for oxide, that is quite big [17:49] And the test suite coverage is for the most part excellent, which helps. [17:49] great to hear that [17:49] I'm creating the LXC container, I'll back when it will finish to download all the internet [17:50] Heh, it does that. [17:50] To start with I'd suggest that you ask us about bugs you're thinking about attacking, and we can advise you if they have any hidden horribleness [17:51] It's been a while since we had non-trivial contributions from outside the core team, so very happy to see somebody interested :) [17:52] you're not in maintenance mode anymore, so I hope also someone more skilled will come out :-) [17:52] Welcome, anyway [17:53] Is there a particular bit of the site that attracts your attention most? [17:54] tbh dunno yet. As I said, I really like bug trackers, so I'll take a look to bug to them - the other thing I think could be pretty improved is integration with bzr, so I'll look also to bugs about code navigations and so [17:54] but, whereever I could be useful I'll try to drop a bit :-) [17:54] OK, fair enogh [17:54] (bit like in 1/8 of byte) [17:54] *enough [17:55] (my english sucks btw) [18:00] cjwatson, do you think bug #194257 could be a good start? Seems very trivial, but could be a good way to take a look to lp tree and to take a look to the workflow [18:00] Bug #194257: "Recently imported branches" doesn't just list recent ones [18:04] rpadovani: Not too hard in itself, but nearby classes in the code include "Recently registered branches" and "Recently changed branches". What would you do with those, since the same change doesn't seem like it would make sense there? [18:05] cjwatson, well, I think it should be evaluted case by case - if there is a check of some type on the datetime I leave the "Recently", otherwise I drop it [18:05] rpadovani: I wonder if a better fix would be to make the code match the text, and impose some kind of cut-off on the list of branches shown [18:06] rpadovani: My point is that neither "Registered branches" nor "Changed branches" makes sense as a page title. [18:06] Okay, so probably is better to show branches that are newer than 1(?) month [18:06] So maybe it would be better to add a filter so that all three of those really are recent. [18:07] great, I'll try this approach then - again, should be easy? [18:07] I'd probably go with something like 90 days, but bikeshed [18:09] changed is fairly easy, but both registered and imported will take you into BranchCollection to add a filter method on date_created, which isn't trivial, and you'd have to figure out how to write tests. I'd class this as relatively easy, but maybe not a first branch. [18:10] (BranchCollection is notably obscure - I had to understand it all recently when implementing a parallel thing for Git) [18:10] okay, thanks for info, so I take a look to other bugs and keep this for next weeks :-) [18:11] https://bugs.launchpad.net/launchpad/+bug/892259 might not be too difficult [18:11] Bug #892259: Link to revision for merged MPs [18:12] You'd have to learn about TAL, but that's going to come up pretty quickly anyway [18:14] Or maybe https://bugs.launchpad.net/launchpad/+bug/530505 [18:14] Bug #530505: branch_merge_proposal.createComment requires a subject, which is pointless

[20:40] rocketfuel-setup is still working ZzZzZz [20:43] Good news: you only have to do it once [20:46] btw, I see it creates two directories, one for branches and one as shadow, so the workflow is bzr switch -b my_little_patch / bzr push lp:~rpadovani/lp-dev/my_little_patch / bzr checkout trunk ? [20:47] I *cough* do things the old-fashioned way and just create a full new branch for everything [20:47] morning [20:48] Though it's a bit slow since I have to do "utilities/link-external-sourcecode && make" in each new branch [20:48] wgrant has a better workflow with "bzr switch" I think [20:48] and you need a big hard disk :D [20:48] We're pretty close to switching to git, though, so don't worry about optimising that too much [20:48] yes, git will make that irrelevant, for better or worse ;) [20:48] morning blr [20:49] how was your weekend cjwatson? [20:49] excellent, thanks, dinner party on Saturday [20:49] much wine was had [20:49] I switched from a directory for a branch to bzr switch a couple of months ago, it has some advantages [20:49] blr o/ [20:49] sounds pleasant! [20:49] rpadovani: BTW the branch URL would be lp:~rpadovani/launchpad/my_little_patch, not .../lp-dev/... [20:50] hi rpadovani [20:50] blr: hope you aren't snowed in or whatever Melbourne has been having [20:51] cjwatson: it has been bitterly cold here, but I think the snow has passed.. the frost isn't budging however. [20:51] cjwatson: did you hear wgrant was without power as well! :/ [20:52] I did [20:53] still, on the upside, we don't live in Portland so http://www.newyorker.com/magazine/2015/07/20/the-really-big-one doesn't have to be immediately terrifying [20:54] yes, read that this morning... I was in the 1989 bay area quake, and that was terrifying enough... [20:55] worst it ever gets here is basically the mild-flatulence level [20:55] though my mother-in-law's house and garage are separated by a fault line, which is kind of interesting [20:56] seismologists seem to be discovering new faults in the south island fairly regularly.. not clear how we stand. [20:57] today I came up with what I think is a workable plan for the gmail filterability project, although I need to try porting something non-trivial like bugs to BaseMailer to see how feasible it is [20:57] ok, a change in direction from your earlier plan, or along the same lines? [20:57] same lines, just a little better fleshed out in that I found a plausible place to put the common code [20:58] and confirmed that gmail actually lets you do reasonable searches/filters for that kind of thing [20:58] looking back through old bugs, it looks like the former Code team developed BaseMailer, and then the tentative plan was for other teams to port stuff to it but mostly nobody ever got round to it [20:58] so I think it's a decent direction [21:00] sometimes I think my job title should be something more like Vinge's "programmer-archaeologist" [21:00] heh, I suppose that's not in the category of jobs that do not exist yet then :) [21:28] I've all up and running \o/ I'm almost moved [22:16] cjwatson: I didn't realise BaseMailer was actually used that widely. That's convenient. [22:28] cjwatson, so, I tried to write the patch to the bug you pointed me to. I hope it's good :-) [22:28] https://code.launchpad.net/~rpadovani/launchpad/link-revision-merged-mp/+merge/264654 [23:09] rpadovani: hopefully that points you in the right direction, let us know how you get on. [23:10] wgrant: potentially it does make sense to have a redirect on code/project/branch/revision/revno perhaps? [23:11] I don't think a slow redirect through the webapp is going to improve people's lives, really. [23:12] rpadovani: You should also figure out how to write and run a test for this. [23:13] rpadovani: The process of doing that would likely have shown up your mistake here.