Re: [Launchpad-dev] Bug page polish
On Thursday 22 October 2009 01:14:56 Tim Penhey wrote: If my picture suddenly gets added everywhere I may have to take the horns off. Wimp! Anyway, I'm not opposed to the logo being shown, but if we do this, lets make sure we do it in the same way for everywhere that gets comments. Yeah, I had that in mind too but didn't make it explicit. I sense some potential refactoring :) ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Bug page polish
On Wed, Oct 21, 2009 at 3:19 PM, Martin Albisetti martin.albise...@canonical.com wrote: Aaron Bentley wrote: - Show the relationship between bugtasks better. Where did the bug originate? Where was it fixed? What is it blocked on? In general, if a bug has a bugtask on a package and on upstream, it's pretty safe to say that it depends on upstream fixing it first. Why? I would think we have the option of fixing it first and then propagating the fix to upstream? Absolutely. So this would be the default assumption, and if it got marked as fix committed/released in a package first, we would flip that around. I say we should assume that by default because, well, upstream bugs *are* upstream bugs, even if we fix them, ideally, we would fix them upstream. Ideally, yes. Practically never. An example, during the many years of Launchpad development we've come across bugs in LP that were actually bugs in our dependencies. Rather than fix the dependencies, wait for a release and use that, we'd often fix or work-around the problem in Launchpad and send a patch upstream. In the case of at least one bug I know, the patch only landed on upstream trunk after a year. What I mean is, getting things upstream is important but rarely ever urgent. - Adding attachments workflow needs to be finished off. Ajaxified, show them in a better way than squished in small a box on the bottom right, attached patches should be shown in the same place as linked branches, and images, in a perfect world, should show a thumbnail. And for patch attachments, provide a way to propose it for merging? That would rock, yes. Or indeed, just turn it into a merge proposal right away. There's a cluster of bugs that I've tagged with 'patch-tracking'. It's something I'm personally quite interested in. I think it would also be interesting to explore pinning a comment as the description like web forms often pin posts, rather than having the description and comments be completely separate things. Pinning comments would be great, yes. Especially for things like this is the definitive answer for this bug. Bugs don't have answers :) jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Bug page polish
On Wed, Oct 21, 2009 at 4:45 PM, James Westby jw+deb...@jameswestby.net wrote: On Wed Oct 21 16:27:49 +0100 2009 Julian Edwards wrote: On Tuesday 20 October 2009 20:57:49 Martin Albisetti wrote: Hello Launchpaderos and Launchpaderas, Hello Duderino. - Being on a roll here, how about highlighting the reporters' comments? His comments will most likely be very important. On a similar note, how about adding the poster's icon next to the comment? +1 Again similarly, adding the user id of the user would be useful to many of us. +1 In Ubuntu development we have quite a few processes where some action is taken because a developer said so in a bug. This is fairly fragile currently as anyone could change their display name to James Westby and make requests posing as me. Another approach would be to somehow intelligently highlight comments that come from people trusted within that project. Some of us that process such requests use a greasemonkey script to display the user id next to the comment, to try and alleviate this (though ~jamesw might still be able to pose as me without being caught). In addition it displays the emblems of some Ubuntu related teams when the person is in them, which is even more robust, and their karma (not really useful here, but can be useful in other cases). It would be good to have this built-in. I realise that working out which team emblems to show could be complex. I think something along these lines would be good. Also, if we do it, let's make sure we do it for comments everywhere, not just bugs. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] RFC: Stopping apport-driven +filebug requests from timing out
Hi folks, We've been seeing repeated timeouts in the +filebug page where users are coming from apport (so +filebugs/$token, to be precise). These timeouts often look like they're happening in the LoginStatus code, but some investigation proves this to be a red herring. My current theory is that: 1. A user comes to +filebug/$token 2. FileBugViewBase.publishTraverse() handles the token, fetches the LibraryFileAlias to which it points and then passes that to a FileBugDataParser. 3. FileBugViewBase.publishTraverse() calls FileBugDataParser.parse() 4. Time passes. 5. More time passes. 6. FileBugDataParser.parse() completes and the request continues, but parse() has taken so long to run (~30 seconds) that by the time the LoginStatus code is being run the timeout limit kicks in and the request is given the nuclear boot of doom. FileBugDataParser.parse() is in fact pretty much one big while loop (lib/lp/bugs/browser/bugtarget.py:187), looping over the contents of the file that apport has attached and dealing with them appropriately. I'm pretty certain that the problem we're having is just one of too much data; the files that were being uploaded by apport in the cases I looked at were circa 90MB in size, and they're going to take a while to parse, whichever way you look at it. Now, as far as I can tell - without studying the loop in detail and trying to find ways to slim it down - the only real way to fix this is to move the processing of the apport data elsewhere, so that it doesn't impact on the user's session. As I see it, the options are: 1. Create a script that processes apport data and make it possible for the +filebug process to tell it Hey, this LibraryFileAlias is mine, please process it and update this bug appropriately after the bug has been filed. 2. Make it so that the apport data get processed before the user is pointed at +filebug, so that the requisite data are available to +filebug as via a series of queries instead of locked away in a BLOB. 3. A variation on option 1, whereby +filebug will only use the asynchronous method for files over a certain size, e.g. 25MB or so). The problem with options 1 and 3 is that we need the apport data before filing the bug, as far as I can tell. The docstring of FileBugDataParser.parse states that the following items are gleaned from apport: * The initial bug summary. * The initial bug tags. * The visibility of the bug. * Additional initial subscribers In addition: * The first inline part will be added to the description. * All other inline parts will be added as separate comments. * All attachment parts will be added as attachment. So at this point, as far as I can tell, only option 2 is actually viable, though it may require changes to apport, too (probably not, but I'm just tossing it in there for the sake of being paranoid). Unless there's some other way of fixing this that I've not thought about at this point (as I said, I haven't had time yet to properly profile the offending while loop to find out if there are savings to be made). I'd appreciate any comments or suggestions you might have. Regards, Graham -- Graham Binns | PGP Key: EC66FA7D ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: Stopping apport-driven +filebug requests from timing out
On Thu, 22 Oct 2009 10:55:00 +0100 Graham Binns gra...@canonical.com wrote: Hi folks, We've been seeing repeated timeouts in the +filebug page where users are coming from apport (so +filebugs/$token, to be precise). These timeouts often look like they're happening in the LoginStatus code, but some investigation proves this to be a red herring. My current theory is that: 1. A user comes to +filebug/$token 2. FileBugViewBase.publishTraverse() handles the token, fetches the LibraryFileAlias to which it points and then passes that to a FileBugDataParser. 3. FileBugViewBase.publishTraverse() calls FileBugDataParser.parse() 4. Time passes. 5. More time passes. 6. FileBugDataParser.parse() completes and the request continues, but parse() has taken so long to run (~30 seconds) that by the time the LoginStatus code is being run the timeout limit kicks in and the request is given the nuclear boot of doom. IIRC, this version of the parser has already been Bjornified and is about a tillenion times faster than it was previously. I guess we're hitting a new limit now. FileBugDataParser.parse() is in fact pretty much one big while loop (lib/lp/bugs/browser/bugtarget.py:187), looping over the contents of the file that apport has attached and dealing with them appropriately. I'm pretty certain that the problem we're having is just one of too much data; the files that were being uploaded by apport in the cases I looked at were circa 90MB in size, and they're going to take a while to parse, whichever way you look at it. Now, as far as I can tell - without studying the loop in detail and trying to find ways to slim it down - the only real way to fix this is to move the processing of the apport data elsewhere, so that it doesn't impact on the user's session. As I see it, the options are: 1. Create a script that processes apport data and make it possible for the +filebug process to tell it Hey, this LibraryFileAlias is mine, please process it and update this bug appropriately after the bug has been filed. 2. Make it so that the apport data get processed before the user is pointed at +filebug, so that the requisite data are available to +filebug as via a series of queries instead of locked away in a BLOB. 3. A variation on option 1, whereby +filebug will only use the asynchronous method for files over a certain size, e.g. 25MB or so). The problem with options 1 and 3 is that we need the apport data before filing the bug, as far as I can tell. The docstring of FileBugDataParser.parse states that the following items are gleaned from apport: * The initial bug summary. * The initial bug tags. * The visibility of the bug. * Additional initial subscribers In addition: * The first inline part will be added to the description. * All other inline parts will be added as separate comments. * All attachment parts will be added as attachment. So at this point, as far as I can tell, only option 2 is actually viable, though it may require changes to apport, too (probably not, but I'm just tossing it in there for the sake of being paranoid). Unless there's some other way of fixing this that I've not thought about at this point (as I said, I haven't had time yet to properly profile the offending while loop to find out if there are savings to be made). It should be possible to stop parsing one we have: * The initial bug summary. * The initial bug tags. * The visibility of the bug. * Additional initial subscribers * The first inline part. These are all early on in the apport blob. Then, later, parse the remainder of the blob: * All other inline parts. * All attachment parts (We could also add a notification to the response saying that this kind of stuff is happening.) A problem with parsing ahead of time is that we then have to figure out how and where to store the results, which may involve some additional serialisation and parsing. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Bug page polish
On Thu Oct 22 09:58:32 +0100 2009 Jonathan Lange wrote: On Tue, Oct 20, 2009 at 8:57 PM, Martin Albisetti martin.albise...@canonical.com wrote: - Being on a roll here, how about highlighting the reporters' comments? His comments will most likely be very important. I think you only want to do this subtly. I know Bryce values his greasemonkey script that does this. It makes it easier for him to deal with the person that reported the my video flickers bug, while telling the others who are commenting on it, but who have completely different symptoms, to file a new bug. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Pre release QA process description
Hello all, I updated and published[1] the description of our pre release QA process. It explains the meaning of the status used in Launchpad's test plans [2] and how can you help testing LP landings and make the burndown graph[3] all green before the release. :-) Let me know if you have questions and/or suggestions. [1] https://dev.launchpad.net/PolicyAndProcess/PreReleaseQAProcess [2] https://dev.launchpad.net/QATeam/TestPlans [3] https://devpad.canonical.com/~lpqateam/test-plan-report-3.1.10.html Cheers, -- Diogo M. Matsubara ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Bug page polish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Albisetti wrote on 20/10/09 20:57: ... I've been thinking about the bug page. I've had a few attempts at creating wireframes of what it could look like, but no matter how much I try, I always get taken down a path that requires radical changes. Nothing wrong with that. :-) As long as any new design is obviously better, and you introduce it all at once to minimize disruption. It's not clear that any of the problems you list require radical changes to solve, though -- they could all be fixed incrementally. Maybe this would be more obvious with a wireframe or two. ... - Show the relationship between bugtasks better. Where did the bug originate? Where was it fixed? What is it blocked on? In general, if a bug has a bugtask on a package and on upstream, it's pretty safe to say that it depends on upstream fixing it first. It doesn't really matter where the bug originated -- what matters is what software it actually affects. As for upstream fixing it first, the Papercuts project is a pretty big counterexample to that. There is a bit of history here, though, which could inspire some simplification. The Won't Fix status was originally intended to be Won't Fix Here, where a bug does affect a project/package but really does need to be fixed elsewhere. (For example, a bug in a library that could theoretically be worked around by an application using the library, but in practice the library should just be fixed.) But people never used it that way; even Launchpad developers now use Won't Fix merely as a euphemism for the harsher-sounding Rejected. Therefore, there is no point in Won't Fix and Rejected coexisting; they should be merged. ... - Also affects... is a mess. You can create another bugtask with 3 different options (Also affects project, Also affects distribution and Target to release). Target to release doesn't do what most people expect, because it targets it to a series. A release comes from a milestone. We need to improve the flow there, maybe collapse the Also affects... into one picker that selects packages or products. Absolutely. http://launchpad.net/bugs/1334 - Descriptions should be more prominent. They describe the bug, they should be more visible. It would help if the description used the same font size as normal Launchpad text. And I think getting rid of the Bug Description heading would help here, too, because it's crowding the space under the Affects table. - Related branches is too vague. If there's a branch linked to a bug, what you're really saying is this probably fixes it. We probably want to show if there are any merge proposals attached to that branch, when it was last updated, and maybe even let you subscribe to it from the bug. In addition to what Aaron said, I'm often now seeing the trunk branch for a project linked to a bug report. I don't know why it's happening, but I'm not sure it's useful to someone reading the bug report. - The subscribers portlet is too long. We have a mockup from a previous sprint on a way to fix that, collapsing all the sections, giving you the description on why they are subscribed in a tooltip and cutting it off after a number of subscribers. It's too long for what? People do, and should, behave differently when commenting on a bug report that has 200 subscribers than on one that has three subscribers. And listing every subscriber is probably the most effective way of communicating that -- more visually obvious than, for example, just giving a count. (You don't actually need to know the exact number, you just need a sense of the audience size.) Another case to consider is: I'm talking about a bug with someone, and they ask me to check that they're subscribed to the bug report. With the current design, I can do this with the browser's Find command. If the subscriber list is displacing other information (e.g. the list of linked blueprints), I suggest moving that information into the main content area. Maybe you don't need to show my name on there if there's already an unsubscribe button? That might be a bit non-obvious. - Adding attachments workflow needs to be finished off. Ajaxified, show them in a better way than squished in small a box on the bottom right, attached patches should be shown in the same place as linked branches, and images, in a perfect world, should show a thumbnail. Yes! And filetype icons for the others. - You should be able to specify that a new tag is an official one, if you have permissions on the project. With some careful design, I think the whole official tags bureaucracy could be abolished. - Tell me how much the bug affects users. Show me the number, show be a flame, but show me something. This could be merged with the subscriber list somehow. - Maybe h1's should be a bit smaller in general, so we don't have so many titles that wrap? Relatedly, it's awkward to have the Edit
Re: [Launchpad-dev] RFC: Stopping apport-driven +filebug requests from timing out
On October 22, 2009, Graham Binns wrote: Hi folks, We've been seeing repeated timeouts in the +filebug page where users are coming from apport (so +filebugs/$token, to be precise). These timeouts often look like they're happening in the LoginStatus code, but some investigation proves this to be a red herring. My current theory is that: 1. A user comes to +filebug/$token 2. FileBugViewBase.publishTraverse() handles the token, fetches the LibraryFileAlias to which it points and then passes that to a FileBugDataParser. 3. FileBugViewBase.publishTraverse() calls FileBugDataParser.parse() 4. Time passes. 5. More time passes. 6. FileBugDataParser.parse() completes and the request continues, but parse() has taken so long to run (~30 seconds) that by the time the LoginStatus code is being run the timeout limit kicks in and the request is given the nuclear boot of doom. FileBugDataParser.parse() is in fact pretty much one big while loop (lib/lp/bugs/browser/bugtarget.py:187), looping over the contents of the file that apport has attached and dealing with them appropriately. I'm pretty certain that the problem we're having is just one of too much data; the files that were being uploaded by apport in the cases I looked at were circa 90MB in size, and they're going to take a while to parse, whichever way you look at it. Now, as far as I can tell - without studying the loop in detail and trying to find ways to slim it down - the only real way to fix this is to move the processing of the apport data elsewhere, so that it doesn't impact on the user's session. As I see it, the options are: 1. Create a script that processes apport data and make it possible for the +filebug process to tell it Hey, this LibraryFileAlias is mine, please process it and update this bug appropriately after the bug has been filed. 2. Make it so that the apport data get processed before the user is pointed at +filebug, so that the requisite data are available to +filebug as via a series of queries instead of locked away in a BLOB. 3. A variation on option 1, whereby +filebug will only use the asynchronous method for files over a certain size, e.g. 25MB or so). Another possibility is that when the user hits +filebug, a page showing a spinner and telling the user Processing apport data That page would fire a job to parse the data, and then you poll every 5 seconds to see if the parse completed. You can do it using AJAX, but you'll need to have a non-JS version that only refresh the whole page every 10 seconds for people without JS. -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Registry standup notes: 2009-10-22
Barry: * Still working on migration. Currently looks good. Python 2.5 + ZTK branch is down to one failure! * 27 failures in Python 2.6 (but before ZTK merge). * Good chance of being done by tomorrow. Brad: * Bug 419742. * Start on bug 455812 - distroseries milestone timeout. * QA Curtis: * Landed +ubuntupkg fixes. * Starting on bug 193469, Unlink (Ubuntu) package from series. Edwin: * Was OCR all day. * Worked on 436507 -- Distroseries source package page has no links to the Distro SP page. In review today. * Follow up on reviews done. * QA * Look for high priority bug. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] lazr-js multiline editor weirdness
On Thu, Oct 22, 2009 at 8:47 AM, Francis J. Lacoste francis.laco...@canonical.com wrote: On October 21, 2009, Deryck Hodge wrote: Take a look at the activation template string in lib.canonical.widgets.lazrjs.TextAreaEditorWidget. There is a formatter config option that takes the XHTML and formats it nicely. This has to be done because the xhtml response is in dd tags via the API. It's also not tested in the lazr-js example because it's dependent on our real XHR response, so it seemed silly to mock just so the test formatted nicely. It's hackish, I know. But I couldn't really work out a nicer way to do it. Leonard, I think we should remove the default HTML view for the API. People don't get that it's meant to be customized. By removing the default view, people will get an error and realize that they have to register their own HTML view for their content, instead of parsing the default XHTML representation and transforming it into what they want. It's the third time around somebody does this!!! Ok, so I had a talk with Francis about this, and then spent the last few hours working with Leonard. With lots of hacking away at my code to get something working. Francis' comment about disabling the default view is misleading. Afterall, I do have a xhtml view for bug description. If he would like the default to die, that's another issue really. :) The problem is really that I'm patching an entire object to update a field, and we need to patch only the field. You can patch using a field uri and do this, which gives back the xhtml representation of the field, and only the field html back. I wasn't aware we could do this. We're others? How has anyone used this if so? I suspect no one has done this, which is why this is the third time for formatter hacks. It seems to me that currently client.js doesn't know how to deal with single field updates. PATCHPlugin seems designed around patching whole objects by building a dict of patch_payload. So I have some code working that changes client.js to allow for both, and I can clean it up later tonight, which is what I plan to do unless I hear that I'm headed down the wrong path. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
