[01:58] Hi! If a template is used in more views, should I define an interface for the template? [02:01] adiroiban, an interface for the template? [02:01] adiroiban, I'm not sure what that means. [02:02] all views using that template, to implement a common interface [02:03] right now we have potemplate-index.pt, potemplate-chart.pt, distroseries-langchart.pt and serieslanguage-index.pt [02:04] they are for different object, but the statistic tables is similar [02:05] I was thinking those templates chould be changed to include a macro for that table [02:11] sorry, I zoned out... [02:11] umm... [02:11] thumper, ^^^ [02:12] if the view is the same on all the pages, then yes, register against an interface [02:12] if it is similar but not the same, then use macros [02:14] they are similar and I start using macros, but I was wandering if we should have an interface for that macro [02:15] you can always read the macro code and see how it is accessing the view [02:16] but I was just wondering if there is a convention for describing a macro. [02:16] thanks! [02:24] I have my own conventions for macros [02:24] but I don't think there are documented and agreed upon conventions for LP devs [02:31] thumper, fight! [02:59] wgrant: Thou spleeny shard-borne bugbear! [03:00] jml: http://uncyclopedia.wikia.com/wiki/Daily_Mail [03:13] landing branches throught pqm takes fricking ages [03:15] Question time: if I work on Code Hosting for Git branches over the next two weeks, will it ever get landed? [03:16] Because I only want to try and attempt if it will be worthwhile. [03:18] So basically: will Canonical consider other VCSs for Launchpad, because I have an amazing idea that I really want to see integrated, and I'd be glad to work on it, only if it would go somewhere. [03:19] Basically: tool-agnostic code hosting. Check out any branch in either Git or Bazaar and work on appropriately. [03:19] magcius: what are you actually proposing? [03:20] thumper, what do you mean? [03:20] magcius: you say you want to integrate git, but how are you proposing doing this? [03:20] magcius: did you see jml's comment above? [03:20] thumper, which one? [03:21] magcius, we aren't opposed to having git support, but we'd want it to work in such a way so that you could use bzr or git for any project on Launchpad, regardless of what it's actually hosted in. [03:21] That one? [03:21] yes [03:21] That was basically my idea. [03:21] Basically, implement a git daemon that accepts pushes. [03:22] how about log, diff, info et al [03:22] thumper, what do you mean? [03:22] I guess the real answer right now is no. [03:22] not at this stage [03:22] I'm not saying we wouldn't consider it later [03:23] but right now we have too much else on [03:23] thumper, okay. [03:24] thumper, the real work would be in converting the object database from bzr to git, right? [03:24] what object database? [03:25] we use postgresql [03:31] err [03:31] I'm thinking too much in terms of git. [03:31] I thought Keybuk told me that git and bzr were a lot closer in their storage model, but I guess that's not true. [03:33] semantically close, but the details of what is stored differs, e.g. bzr doesn't store full file modes, and git stores less commit metadata [03:33] so a lossless mapping is difficult, if not impossible. === stub1 is now known as stub [03:35] james_w, hm, okay. [03:35] magcius, out of curiosity, what is your favorite thing about Launchpad that you'd be so committed to getting Git support in. [03:36] rockstar, the fact that it could be a central place to do everything. [03:36] rockstar, as an advantage, Launchpad has the best bug reporting I've seen [03:36] magcius, yes, but there are many competing code hosting solutions out there that you could use. [03:36] magcius, awesome. That's helpful to know. [03:36] rockstar, to be brutally honest, I'd be content with some way for the Branches thing to link to my GitHub repo. [03:37] magcius, you can say that code is not stored on Launchpad. [03:38] rockstar, my users were getting confused. Because I had forked a project already on Launchpad, they were like "huh? Where's the source?" [03:38] rockstar, I could provide an alternate bzr branch, but that's quite useless when it gets lost among the multitude of branches already there. [03:39] magcius, I think that's a realistic option in the short term. Launchpad already has the concept of "remote branches." Maybe that can be extended to point to git branches as well as bzr branches. [03:39] magcius, but you lose a lot of the niceties that Launchpad provides. [03:40] rockstar, I would also like it if I could fork a project so that I could fix bugs in my project's branch, and still get new bug reports from the old project. [03:40] You're using the term "fork" in the git sense of the word, correct? [03:40] rockstar, because one bug request of "fixed in this branch" that won't ever get integrated into the official one because it's a design decision is disappointing. [03:41] rockstar, basically, I forked notify-osd because I wanted to fix some things that were marked as wontfix. [03:42] magcius, well, to be truthful, as a user, if I wanted the same changes, I probably still wouldn't use your changes because I don't want to have to deal with two different VCSes. [03:42] rockstar, I initially added a branch and marked the bugs as "fixed in my branch", but Marco reverted that status to "wontfix" [03:43] rockstar, I initially hosted them with bzr, but when I started using git for my own projects I hosted it there too. [03:43] magcius: why not have a vcs-import of your git branch? [03:43] magcius: that'll stay in sync [03:44] thumper, because I'd like native support for Git. I have free time and I need a project to work on. [03:44] magcius: native git support will not happen in the short term for launchpad [03:44] full stop [03:44] magcius, I have some projects here you cane have. :) [03:45] thumper, two questions: what time frame does "short term" mean, and why? [03:45] magcius, probably at least the next year == short term [03:45] Alright. [03:45] magcius, the why is because I could stop working on features now, and have at least a year's worth of work in bugs. :) [03:46] When is the release date for "4.0" [03:46] rockstar, alright. [03:46] rockstar, I guess I should start smaller. I'd gladly fix the bugs. [03:46] james_w, I was trying to find some good documentation on the formats and the object model, but I couldn't find any. [03:46] magcius: awesome [03:46] bugs.launchpad.net/launchpad-project [03:46] magcius, I'm sure bzr-git could use your help. [03:46] rockstar, alright. [03:46] magcius, ignore thumper, he's a super crazy. [03:47] rockstar, are you a Launchpad dev or a bzr dev? [03:47] * thumper sups his coffee [03:47] magcius, Launchpad dev, but I (as well as thumper) work on integrating bzr into Launchpad. [03:47] eek [03:47] rockstar, is Loggerhead a Canonical project? [03:47] thumper the oompahloompah [03:48] oompahloompah? [03:48] I'm not that short [03:48] magcius, kind of. [03:48] loggerhead is open source [03:48] magcius, it wasn't started by Canonical [03:48] magcius, loggerhead didn't start at Canonical, but we loves it. [03:48] magcius, and we use in for Launchpad, so we patch it a lot. [03:49] Well.. bzr didn't start at Canonical either :P [03:49] well, yeah it did [03:49] magcius, well, what do you mean by "Canonical project"? [03:49] jml, is it funded by Canonical? Worked on by Canonical employees? [03:49] magcius, I think you could provide some real help on bzr-git: https://bugs.edge.launchpad.net/bzr-git [03:49] magcius, as I said, we patch it a lot. [03:50] magcius, no, but some of those who work on it are Canonical employees as well. [03:50] rockstar, alright. [03:50] rockstar, make Loggerhead easier to use. Every time I try to use it it's a cludge. [03:50] magcius, yes, we're working on it. [03:50] rockstar, make it have the Launchpad masthead with a branch breadcrumb [03:51] I guess I need a good overview on how bzr works internally, which I can't find online. All the documentation I can find is about bzrlib, which I don't care about. [03:51] magcius, yeah, like I said, year's worth of bugs if we stopped getting features. :) [03:51] magcius: rockstar is somewhat busy on other tasks right now [03:52] Sorry if that sounded like a demand. [03:52] magcius, bzrlib is how bzr works internally [03:52] rockstar, well, what's the object format? [03:52] magcius: the best way to get bzr internals is to ask on #bzr [03:52] magcius, if appeal to thumper's emotions, maybe he'll make me work on Loggerhead. [03:52] thumper, okay. Is there a bzr-dev [03:52] I doubt it though. The Grinch's heart is bigger. [03:52] err [03:52] :) [03:52] #bzr-dev [03:52] magcius: no, they are all on #bzr [03:53] okay === thumper is now known as the-watcher === the-watcher is now known as thumper [04:01] thumper: I've updated the Branch destructor web API call branch again [04:01] jelmer: ok [04:03] thumper: but something else seems to be wrong with the diff now [04:03] I was just looking - there's a lot of other changes, but I've only merged lp:launchpad [04:30] hmm... [04:35] jelmer: lp:launchpad is lp:~launchpad-pqm/launchpad/db-devel [04:38] stub: Ah, that explains it - thanks [05:36] gah, my use-testtools branch _just_ missed the buildbot boat [05:36] now I won't get it on stable for 8.5 hrs. [05:43] jml: grats [05:43] [on getting it in at all] [05:49] lifeless, thanks, although I don't count a branch as landed until it hits stable. [06:03] jml: tribunal needs an update for testtools - it doesn't upcall in setUp :P [06:04] oops. [06:05] * jml adds a todo [06:28] jml: Perhaps we should have multiple builds running instead of just one. [06:30] jml: We could have 4 slaves that kick off a build of trunk once per hour if there are revisions landed that are not already being tested by another buildbot. [06:31] stub, that's a good idea [06:35] I think if you wanted to guarantee 15 mins max before a buildbot starts testing your patch and had a 4 hour test suite we would need 16 potential slaves configured [06:38] * jml notes that PQM takes 15 mins to do its thing [08:11] back from nzpug? === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/ [08:16] jml: We've been back for a while (it finished more than 1.5 hours ago) [08:16] jml: But most were out for a while after that. [08:17] evening [08:18] 'lo [08:19] wgrant, I see. [08:20] ha straight on the laptops I see [08:22] what else? [08:22] engaging conversation, a stroll on the waterfront, a round of whist by the fire... [08:23] or something by the fire [08:23] jml: i can tell you haven't been outside for a while [08:23] it's raining now [08:23] mwhudson, heh heh [08:24] http://paste.ubuntu.com/356445/ -- what's going on here? [08:24] i guess you have to edit the prepare script? [08:25] jml: btw, if you want to look at https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-model-code/+merge/16272 and suggest stuff about filenames and so on, feel free [08:26] mwhudson, edit it how? [08:26] mwhudson, I'll take a look [08:27] ta [08:29] mwhudson, I think that all of it could be just as easily in lp/code/ as lp/soyuz. [08:29] yes i guess [08:29] mwhudson, I'm not sure which is better. [08:29] Also, there's that one thing which is in a file that is named strangely. [08:29] recipebuilder.py [08:29] jml: it's a fascist conspiracy that file paths are linear [08:29] mwhudson, indeed. [08:29] wgrant: that's not in my branch, at least :-) [08:30] mwhudson: Ah, OK. [08:35] leonardr, http://paste.ubuntu.com/356445/ is what happens when I try to run 'prepare' in lazr.yourpkg [08:37] jml: do you have any lazr packages elsewhere in sys.path? [08:37] james_w, quite probably. [08:38] jamesh, sorry. [08:38] gror [08:38] * jml confused [08:38] hmm? [08:39] jml: i think you're supposed to branch it as 'lazr.yourpkg' and then run 'prepare' to change it everywhere [08:39] jamesh, sorry, I got your nick confused w/ james_w as sort of a double-misunderstanding [08:40] leonardr, that also doesn't work [08:40] leonardr, http://paste.ubuntu.com/356450/ [08:40] jml: ok, i'll try it [08:40] leonardr, thanks. [08:42] jml: ok, you don't have to branch it as lazr.yourpkg [08:42] but you do have to run bootstrap.py and then bin/buildout [08:43] then you can run bin/py prepare.py lazr.importguardian [08:54] leonardr, thanks. [08:54] leonardr, were there docs in the package that I was missing? [08:55] jml: not really, you're just supposed to know how to run lazr.* scripts from https://dev.launchpad.net/HackingLazrLibraries [08:55] leonardr, ahh ok. [08:56] jml: but yourpkg is kind of a special case, it's not obvious that you have to run buildout on a package you're not going to use [08:56] if you wanted to add some more specific docs to README i'd r= that [08:57] leonardr, thanks. [09:10] Morning [09:12] mrevell, hi [09:12] hey there jml [09:12] leonardr, even after bootstrap & ./bin/buildout, I still get the same error [09:13] jml: just to check, are you using bin/py? [09:14] leonardr, yes. [09:14] hmm [09:14] i got it to work [09:14] leonardr, this is in the lazr.importguardian branch. trying in lazr.yourpkg now. [09:15] I wonder if there's a correlation between liking buildout and being close to the US east coast (where the internet lives) [09:16] nope. :( [09:16] ok, let's try it again [09:22] jml: yes, i'm getting an error now in buildout. you too? [09:22] i think there is a catch-22 here [09:23] james_w/abentley: Hm, I see that the slave returns a file named 'changes'. [09:23] why isn't it the full name? [09:23] leonardr, http://paste.ubuntu.com/356466/ [09:23] leonardr, that's what the first buildout run gives me [09:23] I could hack around that, but it would be preferable to have the full name returned. [09:24] jml: do you have a global cache? you might like buildout better if you set one up [09:24] that's also in HackingLazrLibraries [09:25] wgrant: oh, I noticed that, but I thought it was intended [09:25] we can probably fix it [09:25] james_w: I can't see where it is actually done on the slave side. [09:26] wgrant: That's what's done for a binary build. [09:26] leonardr, ahh, that's a useful tip. thanks. [09:27] jml: and are you sure those errors are fatal? is there a bin/py in your directory? [09:27] leonardr, they aren't fatal. there is a bin/py [09:27] abentley: Oh, yuck. I guess I'll check how process-upload handles that, then. Best not to change the slave. [09:27] running again... [09:29] psycopg2.OperationalError: FATAL: Ident authentication failed for user "launchpad" <- any clues? [09:29] james_w: You've run launchpad-database-setup? [09:29] this is the first time I'm running LP outside a chroot [09:29] yep [09:30] leonardr, http://pastebin.ubuntu.com/356471/ is what I end up with in ./bin/py [09:30] leonardr, I also have lazr packages installed on my system from Ubuntu. [09:31] leonardr, should I be using virtualenv? [09:33] jml: i'm not sure. i eventually had to compile a whole separate version of python. if you run into problems or are already good at virtualenv, i'd recommend it [09:33] abentley: That's only done for a binary build as of your r10153. [09:33] abentley: Previously it used the real name. [09:33] Now I suspect it is broken. [09:34] wgrant: Okay, I'll have a look at it tomorrow. [09:35] abentley: Thanks. [09:35] leonardr, I'm not :( [09:35] leonardr, the HackingLazrLibraries page says there are issues that are being looked into -- is there a relevant bug number? [09:36] 275 + self._slave.waitingfiles['changes'] should be self._slave.waitingfiles[' [09:36] "At this time, a non-system Python, or a virtualenv executable that does not include site-packages, is highly recommended, and may be required. We are working to remove this limitation." [09:36] self._slave.waitingfiles[os.path.basename(path)] I mean [09:36] jml: i don't know about this part, sorry [09:36] leonardr, ok, thanks. [09:37] james_w: Yeah, that's what I've just hacked in. [09:37] james_w: If one of you can commit that to your branch, 'twould be good. [09:37] jml: you might ask gary or (for some reason i associate him with this) bac [09:38] leonardr, is there a lazr mailing list? [09:39] jml: yeeees? [09:39] https://edge.launchpad.net/~lazr-users [09:39] leonardr, thanks. [09:45] * jml is off [09:45] g'night all. [09:51] Oooh. [09:51] Collection works. [09:54] yay [09:55] I have a lot of local changes to bash SourcePackageRecipeBuild into its interface, but it works. [10:48] wgrant: woo [10:50] mwhudson: Took a bit of work, but I successfully (and automatically) went from the SourcePackageRecipeBuild that you told me how to create to a binary package, with not too many gross hacks. [10:50] * wgrant decides to sleep. [10:51] wgrant: very cool [10:51] * mwhudson should sleep too [10:51] (and mthaddon has built buildbot two of the ec2 images already, hurrah!) [10:51] So we can land stuff tomorrow? [10:58] Morning, all. === matsubara-afk is now known as matsubara === mrevell is now known as mrevell-lunch [13:19] adeuring: what does the "structure" keyword in, e.g., mean? It solved a huge problem for me (my output links are correct now, instead of looking like quoted HTML), but I'm not sure what magic did this... [13:20] kfogel: it prevents escaping of '<' and '>' [13:20] ...in the text that is inserted [13:20] adeuring: aaaah, "structure" as in "interpret this as the 'structure' of an HTML page instead of as content" ? [13:20] kfogel: yes [13:21] adeuring: interesting. Very useful; not the keyword I would have chosen, but then I guess it's hard to think of words that will be intuitive under all circumstances. Anyway, thank you. Big light bulb for me :-). [13:21] kfogel: welcome :) The general idea is: Use "structure" only for trusted data; any user provided text must not be rendered this way. [13:22] adeuring: *nod* thanks. In this case, it's expanding our own bug link, so it's safe (though users can set the titles of bugs... I presume we already filter that in the bug tracker itself?) [13:24] kfogel: well, the title is considered as text, so it should not be rendered with the "strurcture" keyword. That's even necessary, otherwise writing a title like "1<2 returns False" would be a bit cumbersome [13:25] adeuring: one sec, let me show you diff and screenshot [13:26] kfogel: and sure, using "structure" to render a link is absolutely fine -- that's the indended usage [13:26] kfogel: escaping the title is in this case the job of the fmt.link renderer [13:27] s/fmt.link/fmt:link/ [13:28] adeuring: http://paste.ubuntu.com/356555/ [13:28] adeuring: so that's a correct use of structure? [13:28] kfogel: yes [13:28] adeuring: thanks [13:28] kfogel: welcome :) === mrevell-lunch is now known as mrevell [14:37] morning flacoste! [14:38] morning mars! === matsubara is now known as matsubara-lunch === salgado is now known as salgado-lunch [15:22] adeuring, deryck, intellectronica: what free software tools do you like for making mockups? I can just use inkscape or gimp or whatever; I'm just doing a rough sketch for Bryce right now, and wondered if you had any tools you love. [15:23] kfogel, with image-based mockups I use gimp. I use balsamiq (not free) for free-from, sketch-type mockups. [15:23] kfogel: pencil, paper, scanner and Sane? [15:23] adeuring: :-) could work [15:24] kfogel: problem is though that only Sane is free in this setup... [15:25] kfogel: inkscape is quite good for sketching. if you're willing to compromise on freedom balsamiq is very good and we have a group license for it (given by balsamiq gratis to free software projects) [15:25] adeuring: they're all libre. in fact, I think I libre-ated some of my pencils from the Software Freedom Law Center a few weeks ago. Don't tell. [15:26] intellectronica: I don't have a moral opposition to using non-free software, I just hate spending time acquiring skills in something that can be taken away at any time, if you know what I mean -- seems like a poor investment usually. [15:26] kfogel: ;) And you can take paper from your recycling bin. Would also be free in some sense... [15:28] kfogel: yes, it's a fine balance. and even balsamiq is not free of problems. it's built on adobe air, which doesn't work very well on linux (shortcut keys don't function) and there's absolutely nothing you can do about it [15:38] intellectronica, "shortcut keys don't function" - really? All of them? They've all worked for me so far. [15:40] mars: oh really? maybe something is borked about my installations (more than one, both in jaunty and karmic) but ctrl-c, ctrl-v, ctrl-x don't work, which is a pain in the ---- [15:41] kfogel, you can export balsamiq mockups as .png for sharing, and their interface makes it very easy and streamlined to do so (easy to use UI from a UI design product company - go figure) [15:42] intellectronica, those keys work fine for me here - GNOME on Karmic [15:43] hmmmm ... not that i have the time or patience to try fixing that now, but at least there's hope! :) [15:45] kfogel, if you go for Balsamiq and are running a 64bit OS, I have some simple instructions for getting AIR running. [15:45] mars: thanks === matsubara-lunch is now known as matsubara [15:59] Chex, gary_poster, rockstar, daniloff, sinzui, allenap: meeting in 1 min @ #launchpad-meeting [15:59] henninge, can you cover for danilo? === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado === henninge_ is now known as henninge [16:55] sinzui: what does the SourcePackageRelease.component column mean? [16:57] EdwinGrubbs: main, universe, multiverse [16:57] EdwinGrubbs: Main is of course the packages most often used by Ubuntu users === beuno-lunch is now known as beuno [17:10] sinzui: shouldn't you limit which bugs you count by the date they were created? If a package is obsolete it should be significantly less important. [17:12] EdwinGrubbs: are any obsolete packages in the listing? I was assuming that they way they are joined they are current (latest release) [17:14] sinzui: I don't know enough about those tables to say. Even if they are not to-be-removed from Ubuntu, they may be less important because a new piece of software is much better. [17:15] EdwinGrubbs: I suppose `spph.supersededby is not NULL` would ensure the that the package is current [17:16] EdwinGrubbs: when a package is removed from a distroseries, the spr is removed, which is what causes the message in the sp +index that the package is not in the series [17:20] EdwinGrubbs: I think the status of published means it is current so a constraint like `spph.status = 2` will work [17:25] sinzui: what is the most important thing that will happen after these items are linked? Build a new binary package in Ubuntu or in a PPA? [17:28] EdwinGrubbs: ppa are not used in buildin ubuntu. [17:29] EdwinGrubbs: The most important thing is to then ensure the branch, bugtracker, and translations are setup so that bugs are forwarded, translations synced, and tip is included in the daily builds [17:35] sinzui: it just seems odd that nagios-plugins would be ranked higher than sun-java6 and postfix. [17:36] sun-java is not in main. [17:37] * sinzui looks for popcon data [17:38] sinzui: it seems that buggier apps will get prioritized over those with a lot of bug heat for a few bugs. [17:39] EdwinGrubbs: yes. I do not want to write queries that will kill the page (just like i did in November) [17:40] EdwinGrubbs: nagios-plugins are pretty popular [17:41] EdwinGrubbs: I am not sure heat in needed to this prioritisation to be successful. [17:43] sinzui: the heat was just an idea, but I don't think it's that important. I do think that a component package with zero bugs and zero translations shouldn't win out over a non-component package with bugs or translations. [17:44] EdwinGrubbs: yes, I saw that. the main rule was that last thing I added. [17:45] sinzui: otherwise, I think the heuristics are good. It would probably make it easier to update the query if you put it in a subquery so that you could use "ORDER BY score DESC" [17:45] EdwinGrubbs: instead of counting the bugs, I could sum the bug.hotness, but the default is 0 so I need to verify 1 is the effective value since there is always on subscriber [17:46] EdwinGrubbs: great idea, I'll try that [17:50] EdwinGrubbs: r=me for the API branch. I have one suggestion in my review. [17:50] thanks [17:52] EdwinGrubbs: the two packaging queries use spph.status IN (1, 2) which means the package is pending or published. There are no deleted or obsolete packages in the listing [18:13] EdwinGrubbs: Switching to sum(hotness) instead count(bugtask.id) creates an interesting change in the top 15 (I used LIMIT): http://pastebin.ubuntu.com/356690/ [18:14] night === deryck is now known as deryck[lunch] [19:10] morning [19:11] Morning. === deryck[lunch] is now known as deryck [19:21] sinzui: that is interesting. maybe, it should be (hotness/10)+count so that desktop apps don't have such an advantage over libraries. [19:22] EdwinGrubbs: I'll try that. I have already changed main component to 1000 and increased the po_message core by a multiple of 5 [19:35] mwhudson, hey. When's the LH patch going to be tested? I'm anxious to see if a 20 line patch fixes everything :) [19:35] beuno: it should automagically hit production "at some point" [19:36] we should really stop using voodoo to deploy launchpad [19:37] looks like it's rolled out at 22:30 utc [19:37] so ~3 hrs [19:38] * beuno crosses fingers [19:57] kfogel, another alternative to show the patch-er [19:57] is to show the one with most karma [19:58] (most active in LP) [19:59] beuno: interesting idea! [19:59] beuno: I'm a little worried about karma becoming a positive feedback loop; but, we could at least show karma when we show a user at all. [20:01] morning === matsubara is now known as matsubara-afk === salgado is now known as salgado-afk [20:12] intellectronica: ayt? [20:13] wgrant: Could you please take a look at comment #2 in https://bugs.edge.launchpad.net/soyuz/+bug/507323 [20:13] Bug #507323: Candidate job selection logic needs to observe the 'virtualized' setting [20:17] deryck: got time for a quick call about code design? [20:17] (not vital, just would help; I can stumble through the underbrush on my own too) [20:20] beuno: have you seen the "mockups" in bug #506018? [20:20] Bug #506018: Need a "+patches" view: report lists patches attached to bugs. [20:21] kfogel, I have. I've been spying on the thread [20:22] the "..." may not be the most obvious and clickable thing :) [20:22] beuno: yeah. Maybe the words "(most recent)" next to the patch age? (and the words would not be a link) [20:23] sometimes one can try to do too much with icons! [20:23] kfogel, I think I'd just not link it [20:23] and [20:23] I've also been thinking about this number [20:23] beuno: the patch age? [20:23] instead of days/weeks/months [20:23] yes [20:23] we need to indicate units [20:23] right now I'm assuming it's days [20:23] user may not know that though [20:23] right, I'd add that explicetely [20:24] agreed [20:24] maybe for multiple patches [20:24] you could do: 61 days (2) [20:24] should the patch age itself be a link to anything? I'm beginning to think not. It should just provide the hover-over popup. [20:24] beuno: that'd be confusing, though -- is it saying there are 2 patches that have been there for 61 days? [20:24] I think that unless you take them directly to the patch or something, no link [20:24] that's not the case [20:25] it would sort of imply that [20:25] well, going directly to the patch, hmmmm... that's an idea. We provide a snippet of it in the popup, then they can click directly to it to investigate more. [20:25] not sure it's terrible [20:25] how about "61 days (youngest)" ? [20:26] well, how important is it to know that the other ones are older? [20:26] It's somewhat useful to know there are other patches there, but it may not be worth the UI clutter. [20:26] Bryce seems to think not hugely important. [20:26] We can just leave it out for now. [20:26] We're going to talk to an upstream dev too (jorge is finding) so we can ask him. [20:26] But for now I'll code assuming we just show the youngest and that's that. [20:26] I think it's good to know there are more patches, but not super necessary to know that the "other ones" are older [20:27] adding the number between brackets is not super correct, but helpful enough :) [20:27] beuno: true, though that will always be the case [20:27] and don't show it if there's just one :) [20:27] umrmph [20:27] I am afraid that number is going to be confusing. let's see what bryce & upstream dev say [20:27] sure [20:28] kfogel, I'd also link the packages to their bug listings [20:28] and, of course, importance/status with the colors [20:28]