| === broder_ is now known as broder | ||
| === timrc is now known as timrc-afk | ||
| evfool | hey all, I would be interested in implementing a launchpad bugtracker plugin, and need to know whether a bug tracker plugin can modify the bug title on launchpad | 11:24 |
|---|---|---|
| wgrant | evfool: Launchpad bugwatches can only import status and importance. | 12:02 |
| wgrant | cjohnston, cprov: Joining? | 12:02 |
| cjohnston | I'm in there | 12:02 |
| wgrant | Are you sure? | 12:03 |
| evfool | wgrant: meaning that if I would like an integration with an external site which does change the bug title, I would have to modify the launchpad core, and that's probably not going to get accepted (just for the sake of providing better integration with an external bugtracker) | 12:23 |
| evfool | ? | 12:23 |
| wgrant | evfool: Bugwatches aren't really meant to do that. They're usually used by projects or distributions that use Launchpad's bugtracker, and they mostly want Launchpad to tell them when the same bug on a remote bugtracker is fixed. | 12:32 |
| wgrant | So it shouldn't automatically change the Launchpad title. | 12:32 |
| wgrant | What are you trying to do? | 12:32 |
| evfool | wgrant: bountysource integration, but the only pluggable thing I have found in launchpad are bugtrackers, which bountysource is | 12:33 |
| evfool | see bug 1325045 | 12:33 |
| _mup_ | Bug #1325045: Bountysource integration [$100] <Launchpad itself:New> <https://launchpad.net/bugs/1325045> | 12:33 |
| wgrant | That doesn't seem like a good fit for bugwatch integration. | 12:34 |
| wgrant | Why do you particularly want it integrated in Bugs, or indeed Launchpad at all? | 12:34 |
| evfool | wgrant: the elementary project uses bountysource to provide bug bounties, and uses launchpad for bug tracking, code reviews, merge proposals and others | 12:35 |
| evfool | wgrant: when adding a bounty, that appears only on bountysource, and they would like better integration with launchpad to have some sort of status on bugs with bounties about the bounty | 12:36 |
| evfool | currently, each bug gets manually commented with a link to the bountysource issue, the title gets updated to contain the bounty value, and occasionally a bounty tag is added too | 12:37 |
| wgrant | I'd suggest a bot using the Launchpad API instead | 12:37 |
| wgrant | I think that makes more sense than a bugwatch here. | 12:37 |
| evfool | wgrant: thanks, I'll look into integrating from the other side, through a bot making the changes | 12:38 |
| wgrant | You can file a bug using the createBug method on https://api.launchpad.net/devel.html, using https://help.launchpad.net/API/launchpadlib | 12:38 |
| evfool | wgrant: bounties get added to already existing launchpad bugs, so I'm not gonna create tickets, but I'll look for updateBug then | 12:39 |
| evfool | thanks for your help | 12:39 |
| wgrant | cprov, cjohnston: http://pastebin.ubuntu.com/7587437/ gets it down to six queries per translated string. | 13:21 |
| wgrant | I'm not sure the second change is totally correct in the presence of shared POTMsgSets; we need to entire that the TranslationMessage has the correct POFile set, not just getOnePOFile | 13:21 |
| cprov | wgrant: CurrentTranslationMessageZoomedView.zoom_url calls self.sequence too | 13:23 |
| cprov | wgrant: self.context.sequence should fix it | 13:24 |
| wgrant | cprov: I'm not seeing duplicated queries from that here. | 13:24 |
| wgrant | Though we shouldn't be using the ZoomedView multiple times one on page anyway | 13:26 |
| wgrant | That's why it's zoomed. | 13:26 |
| wgrant | I'm not sure how much further we can reasonably go here without combining the views. | 13:27 |
| wgrant | So turn the CurrentTranslationMessageView thing into a view that actually renders somewhere between 0 and infinity of them | 13:27 |
| wgrant | Running all the suggestion queries etc. in bulk | 13:28 |
| wgrant | We could hack this into the model, but it's going to be ugly and I'm not sure it's worth it. | 13:28 |
| wgrant | cprov: What do you think? | 13:28 |
| cprov | wgrant: I think it will be a long journey, considering the current code shape | 13:29 |
| wgrant | It's going to be either way | 13:29 |
| wgrant | The view code does all the suggestion etc. calculations itself | 13:29 |
| wgrant | We need to move that somewhere higher up | 13:30 |
| wgrant | I'm not sure how much per-message code is left once we do that | 13:30 |
| wgrant | And anything that is left is probably crap :) | 13:30 |
| cprov | agreed, minor amendings are not getting us anywhere | 13:31 |
| cprov | they will probably take as much time and break as many tests as writing a string-batch-loader from scratch. | 13:33 |
| wgrant | The code in question is mostly browser/{pofile,translationmessage}.py, right? | 13:33 |
| wgrant | It's big and ugly, but I think it's probably worth basically doing a massive refactor which turns it into a megaview. | 13:34 |
| wgrant | Hacking the bulk loading in is only going to make it worse, and it's already like 10 years of hacks | 13:34 |
| cprov | wgrant: well, the megaview would still be in charge of doing the bulk loading of subviews, no ? | 13:39 |
| wgrant | cprov: I'm not sure there'd be many subviews. | 13:40 |
| cprov | or do you mean to collapse those too ? | 13:40 |
| wgrant | Almost all of the logic would end up in the megaview that renders n messages | 13:40 |
| wgrant | I suspect the per-message templates would end up as macros, not entire views. | 13:40 |
| cprov | makes sense | 13:41 |
| === timrc-afk is now known as timrc | ||
| wgrant | cjohnston, cprov: I'm done, be back in a sec if you want to hang out again yo. | 13:57 |
| cjohnston | k | 13:57 |
| wgrant | So many queries :( | 14:01 |
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| === wallyworld is now known as Guest56344 | ||
| === wallyworld is now known as Guest68975 | ||
| === timrc is now known as timrc-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!