[00:02] intellectronica: saw your branch get linked just now [00:03] kfogel: yes. had a chance to look at it? [00:03] intellectronica: not yet, about to [00:03] i think it's good to go [00:04] intellectronica: in this comment, "lisp-style identifier" means with hyphen instead of camelCase, right? [00:04] Is this a new CSS class or an existing one. If it's new, let's change it to [00:04] lisp-style-identifier. Otherwise don't worry about it. [00:05] kfogel: right. sorry for not being clearer. [00:05] intellectronica: no, I think you were clear -- just you were here, so I thought I'd check to make abs sue. [00:05] sure [00:07] intellectronica: also, you wrote this: "Repeating the same style over and over again kinda' screams CSS class." [00:07] but making a new class for this feels wrong -- I'd think the right class already exists somewhere. Do you know if there's one I should use? [00:07] This is for the table cells in the patches view. [00:07] kfogel: i have no idea. launchpad's css is a messy business, but look at the file and if you don't find one feel free to add [00:08] intellectronica: "the file" is lib/canonical/launchpad/icing/style-3-0.css or lib/canonical/launchpad/icing/style.css [00:08] ? [00:08] or somethig else? :-) [00:09] kfogel: lib/canonical/launchpad/icing/style.css, i think [00:09] there's a section in it dedicated to the bugs application, so it should be ok to jsut add the class there [00:11] thumper: poing [00:11] intellectronica: oh, and I'm taking the "" out of the script type=text/javascript block. Thanks for the comment about the 90s calling :-). [00:12] :) === mpt_ is now known as mpt [00:16] rockstar: if you *are* in the reviewing mood though, https://code.edge.launchpad.net/~mwhudson/launchpad/less-import-requestMirrors-bug-487357/+merge/18361 [00:17] mwhudson, I assume you're probably pretty lonely in your hemisphere currently, so I would review it even if I wasn't in the mood. [00:17] rockstar: indeed; thanks [00:22] mwhudson: ping [00:22] mwhudson: I'm going to nag you as thumper seems awol. please see up about one page for the bug link I threw at him [00:27] intellectronica: what I'm going to do is make an integration branch with your branch, my brancha, and allenap's branch (adding patches view to persons/teams), and run that integration branch through EC2 tests. I assume if we get review on the three branches, then when the integration branch passes tests, we can merge each of the three individually to devel, right? [00:27] kfogel: yups [00:30] kfogel: or bomb the lot in :P [00:30] intellectronica: want to review https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414 ? [00:30] lifeless: well, how does one write the PQM submit message for that? :-) [00:31] kfogel: "foo bar baz" [00:31] I'm thinking what the combination of "[r=foo...]" on the front would be. [00:31] ah [00:31] ok [00:31] maybe I'll just do that [00:31] intellectronica: thanks [00:37] intellectronica: btw, do you need to get review on https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message ? (I am not a reviewer, unfortunately.) [00:37] (s/unfortunately/fortunately/, as you please :-) ) [00:38] lifeless: thumper is in london [00:38] kfogel: i do need to get a review, yes [00:39] intellectronica: is that something I can submit, or do you have to do it? because if I could, I'd pick one of these gents currently in the channel (assuming cross-team reviews are kosher). [00:39] kfogel: wow, if you feel like doing that that would be super awesome, because i'm dying to go to bed [00:39] but don't feel obliged [00:39] lifeless: do you know if 2.1rc2 will be out soon and if it will have the fix? [00:40] intellectronica: remember, I'm just submitting to someone else, not reviewing. But sure, I'll create a merge proposal and point to some test data for them, etc. [00:40] kfogel: approved allenap's branch, b.t.w [00:40] intellectronica: great! [00:40] kfogel: you rock [00:40] * intellectronica --> zZz [00:40] intellectronica: if tests pass, and the other branch passes review, then tomorrow we are all focused on the patch-age sorting, because IIUC that's the only thing left. [00:41] intellectronica: good night! [00:41] mwhudson: soon yes [00:41] mwhudson: otoh this bug is going to be biting people, 2+ reports of it a day at the moment (judging by malone + hallway conversations here) [00:42] hmm [00:42] i wonder if the diff applies cleanly to the bzr we're currently running... [00:42] yes, it will. its a tiny patch [00:43] ok cool [00:46] mwhudson, thumper: will y'all be around, say, an hour from now? [00:47] kfogel: i will, thumper won't (i really hope) [00:49] +upgrade is severely lacking in the text department. [00:49] And it seems to be letting me upgrade a branch on which others are stacked. That seems bad. [00:49] mwhudson: I may hit you with an easy review request a bit later then :-) [00:49] kfogel: ok [00:51] wgrant: you have to be able to do that [00:57] lifeless: Yes, but there's this nice clicky button with no explanation that will let me break everything. [00:57] Huh, ec2 missed the fact that my branch wasn't up to date... [00:59] rockstar: thanks [00:59] rockstar: it's possible the branch hadn't been mirrored by the time ec2 grabbed it? [01:00] mwhudson, no, my public branch was out of date. [01:00] oh [01:00] * rockstar shrugs [01:01] rockstar: hi [01:01] rockstar: so, the upgrade button seems to show up right after push until the branch is scanned [01:01] rockstar: I presume the default value in the table causes it to be shown [01:01] lifeless, :( [01:02] lifeless, can you please specify that in the bug? I'll fix it tomorrow. [01:03] rockstar: cool, thanks [01:03] lifeless, no, thank you for reporting and following up on the bug. I really appreciate it. [01:04] anytime, its easy karma :) [01:06] mwhudson, could we chat really quick? I'm trying to figure out some of jml's suggested voodoo that I bet you know a lot about. [01:06] rockstar: sure [01:06] (i've even found my headset now) [01:06] mwhudson, yay! [01:07] mwhudson, http://pastebin.ubuntu.com/367205/ [01:08] mwhudson, http://pastebin.ubuntu.com/367206/ [01:18] mwhudson: so you're going to cherrypick the fix ? [01:18] lifeless: i guess i should [01:19] * mwhudson tries to remember what the process is for using non-released versions of sourcedeps is [01:19] rockstar: i'm not going to land the bzr upgrade until after this cp is sorted [01:19] rockstar: so don't rush things on my account [01:19] mwhudson, well, I was already rushing. :) [01:20] heh [01:24] mwhudson: rockstar was landing another non released version for bzr-loggerhead [01:24] mwhudson: so build on that :) [01:24] mwhudson: for now, I'd like to assign the bug to you and bump to critical [01:24] mwhudson, well, I'm actually doing one cherry pick at a time. [01:39] Is there a dev wiki entry on landing against the production branches? [01:39] mwhudson: https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 [01:40] rockstar: does dev.launchpad.net/Trunk link to what you need? [01:41] kfogel, no. [01:41] rockstar: pity [01:41] :-) [01:42] kfogel, I'm looking for the instructions for landing against production branches. [01:43] rockstar: they may not be in the dev wiki. Is this different from landing against one of the four usual horsemen (db-devel, devel, stable, db-stable)? [01:44] rockstar: i.e., I'm not clear on the shorthand "landing against production branches". [01:44] kfogel, yes. I need to land against what's in production right now. [01:44] kfogel, none of those four are currently deployed. [01:45] kfogel, AIUI, I submit to PQM with a release-critical against a production db. [01:45] rockstar: you mean you need to land your change into production right away?? (Sorry, I'm not being deliberately dense, I'm just not clear on what you're trying todo.) [01:45] kfogel, yes. I have a high priority issue that needs to get cherry picked to production. [01:45] rockstar: I'm not expert in this, having never done it, but I thought you just land the change on one of the regular trunks and then request a cherry pick. [01:45] The request can be by email? check with mthaddon or someone who might know better. [01:45] what kfogel said [01:45] no, it has to be landed on production-devel [01:45] doesn't it? [01:46] errr.... [01:46] mwhudson, yea, I think that's new. [01:46] which ties up pqm for like 14 hours [01:46] mwhudson: but that's what the cherrypick does, no? [01:46] don't you land against one of the rarely used, yet still in PQM branches? [01:46] spm, yes, and I'm trying to figure out which one. [01:46] i think there is much talking past each other going on here [01:46] After it lands, I then beg a LOSA to deploy it to production. [01:46] I'm just trying to find a wiki page on how to do it. [01:46] rockstar: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/production-devel [01:47] mwhudson, thanks. [01:47] mwhudson: (I don't think so; I think it just took a moment to figure out the goal) [01:47] rockstar: this should be a note somewhere on dev.launchpad.net/Trunk [02:11] mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/513432 metadata twiddled. [02:11] Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' [02:11] for now, dinner time here. [02:12] wowwwwwww... combination of "<<<<" ">>>>" conflict markers and story test ">>>" lines is... dazzling to the eye. [02:12] * kfogel rubs his eyes [02:38] james_w: Oh, 2.5 is going to be gone entirely? [02:38] that's the plan [02:39] 2.5->2.6 was less painful than 2.4->2.5 so there's less holding it back, and moving to 2.6 only means that we can move quicker towards python3 [02:39] The intention has been to only move LP to 2.6 once Lucid is out and the DC is upgraded. [02:40] that could make things tricky [02:41] Yes. [02:41] we can always stick 2.5 in a PPA for those couple of months, but it would obviously be better if there were fewer PPAs involved [02:41] I think everybody thought that 2.5 would remain like 2.4 did. [02:41] We already have 2.5 rebuilds of most stuff in the PPA. [02:44] mwhudson: any idea what this is about? I see the import line right where the error message implies it is, but I have no idea what it means nor why it has never happened to me before :-). [02:44] http://paste.ubuntu.com/367245/ [02:45] kfogel: make build? [02:45] https://lists.launchpad.net/launchpad-dev/msg00071.html ... [02:45] mwhudson: oh, hmrm. I'd done successful 'make run', I thought. But let me do make build, let's see. [02:46] mwhudson: *embarrassment* [02:46] mwhudson: my 'make run' was in the wrong branch. nothing to see here, move along... [03:34] allenap, intellectronica, just in case anyone of you is still around, I got Person.searchTasks() working in my branch, it still needs some more tests, but I'm getting there [03:35] thekorn: they're in bed (and I'm about to be) but they'll be on in the morning UK time [03:36] ok [04:03] kfogel: reviewed that branch, finally [04:09] mwhudson: thanks. I think I should have explained that only Tom Berger's changes needed review -- but actually, you've saved us time by reviewing a lot of my recent changes too :-). [04:09] kfogel: oh [04:09] well, i just reviewed the diff :) [04:11] mwhudson: I meant allenap, but same thing. [04:11] mwhudson: yeah. That's kind of a bug, in that "the diff" was the wrong thing. I'm sure there was a way for us to set things up so it would be the right thing, but I didn't do that... [04:12] mwhudson: no, I was right the first time: intellectronica, sorry [04:35] hey mwhudson, I have a question that you might know the answer [04:36] Ursinha: shoot [04:36] mwhudson: what exactly sets the properties of a bzr revision? [04:36] Ursinha: in what context? [04:37] mwhudson: I'm using bzrlib to get all the lp commits, one by one, and looking in its properties for the name of the "original" branch [04:38] oh right [04:38] mwhudson: and I just hit one that has no properties set [04:38] well, there's the branch nick i guess [04:39] Ursinha: in some sense, there's not much more of an answer than "bzrlib" [04:39] hm [04:39] there are some common properties, but none you can absolutely 100% rely on [04:39] mwhudson: I see [04:39] particularly given how old a codebase launchpad is [04:40] I was counting on the branch-nick property, and then it exploded because a revision had no branch-nick property [04:40] yeah [04:40] i think you just have to cope with that case [04:41] mwhudson: I'm trying to find one alternative way to get the bugs related to a commit besides people having to add the bug tag to the commit message [04:42] Ursinha: ah, i see [04:43] I know that this is automagically added to the commit message when you use ec2 land [04:43] mwhudson: I think I'll keep relying on the commit message now the bug is added without intervention [04:43] do you have any ideas? :) [04:44] Ursinha: not really [04:44] mwhudson: I mean, do you know a way of getting to a list of related bugs from a branch revision? [04:44] Ursinha: well, if the associate was done with ci --fixes lp:12345 then it's a revision property [04:45] if the fix was recorded in the web ui, then no, not from the bzr branch [04:46] mwhudson: I was thinking about getting the branch nick, then the owner, and searching for the original branch in lp, and getting the list of linked bugs... [04:47] Ursinha: that would most likely work, i guess [04:47] mwhudson: yeah, that works but it's slow and if you don't have a branch-nick, it fails [04:47] Ursinha: really, you want to get the branch with tip revid that of the rhs parent of the mainline commit [04:47] Ursinha: which is easy if you have db access :-) [04:49] mwhudson: trying to understand what you mean here :) [04:50] Ursinha: all mainline commits for launchpad are merges made by pqm [04:50] so the revisions have 2 parents [04:50] mwhudson: right [04:50] pqm and the owner's [04:50] the second parent revid is the tip revision of the branch being merged [04:50] so if you can find the branch with a given revid as its tip revid, you can find the merged branch [04:51] hmmmm [04:51] (well, probably, unless the branch has been deleted or something, but then you're SOL anyway) [04:52] mwhudson: so searching in the db for the branch using the tip revid [04:52] I wonder if that's overkill now [04:52] Ursinha: i think using the branch nick is probably a reasonable approach for now [04:52] Ursinha: we could export "get me the branch with tip revid $foo" over the api i guess [04:53] (maybe it is already! but i doubt it) [04:53] mwhudson: that would be neat [04:53] mwhudson: I couldn't find it [04:53] Ursinha: it's probably not there then [04:53] I see I can search using the branch url or the unique name [04:53] i don't think it's even an internal api [04:53] hm [05:01] mwhudson: is that bug 356360? [05:01] Bug #356360: API call for finding branches that contain a revid [05:02] Ursinha: looks like it! [05:05] mwhudson: :) === thekorn_ is now known as thekorn [08:25] Morning ppl [08:25] Good morning noodles775 :) [08:25] Morning. [08:29] morning [08:29] wgrant: I bet it isn't morning for you :) [08:29] thumper: Not quite, no. [08:30] mwhudson: around at all? [08:33] good morning [08:33] moin adeuring [08:33] hi al-maisan! [09:08] thumper: ish [09:08] mwhudson: what's the status of the bzr update cp? [09:09] thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/apply-fix-for-bug-513432/+merge/18435 [09:10] mwhudson: was it branched from the production branch? [09:10] thumper: no [09:10] mwhudson: I'll get flacoste to rc it [09:10] mwhudson: hmm [09:10] thumper: but i think it'll cherrypick cleanly :-) [09:10] if you want to land on the production branch, you'll need that [09:11] we don't tend to CP any more [09:11] we just merge a branch into production [09:11] sure [09:11] but merge into devel first? [09:11] mwhudson: yes, normally [09:11] hi [09:12] thumper: you can review it for that then :-) [09:12] mwhudson: you might want to replace the branch content with the same content but from the production revision [09:12] yep [09:14] done [09:14] mwhudson: so land on devel and I'll have flacoste rc approve before lunch [09:16] thumper: at the risk of sounding churlish, it's 22:14 here [09:16] thumper: want to do it yourself? [09:26] mwhudson: Enjoy your evening. I'm assuming there was nothing that stood out as drastically wrong when you went over the bfb ui? [09:26] noodles775: no indeed [09:26] Great, thanks for that. [09:28] * noodles775 writes the email to get wider feedback. [10:02] james_w: the bad news are that your patch didn't land because of test failures. the good news is that looks like these are unrelated, spurious failures [10:02] some good news... [10:03] mwhudson: thanks a lot for the review. i guess karl forgot to mention that mine was a tiny branch, dependent on his previous work? [10:06] mwhudson: anyway, you didn't make any comment about my work, so i'll interpret that as r=you and ask karl to look the rest of your comments. sorry that you had to do so much extra work (i'm sure the comments are valuable, though). === matsubara-afk is now known as matsubara [11:15] intellectronica, hey, I have Person.searchTasks working for the webservice API in lp:~thekorn/launchpad/make_iperson_ihasbugs, it already has two (doctest) testcases, I'm wondering how many of them do I need, and esp. where to put them [12:02] henninge: what went wrong with my branch to check for unique template names? [12:02] danilos: Hi. Should I create a MP for bug 340664 , or since the performace issue is not solve, it is better to not push those changes? [12:03] Bug #340664: Add administration page for all POTemplates in ProductSeries or DistroSeries [12:03] adiroiban, sorry, in the meeting [12:03] henninge: ahhh, let me guess: you ran into the problem before my fix had landed? [12:03] adiroiban: if there's a performance problem... it's not the one where Language is being queried far too often? [12:04] jtv: i don't think. This is for the +templates [12:04] jtv: I had checked the revisions but mixed up some numbers ... [12:04] and afaik this is a long standing issue [12:04] adiroiban: makes sense, but thought I'd better ask [12:04] henninge: right, I don't think it's on staging yet—it only just came out of EC2. [12:05] henninge: s/staging/edge/ [12:05] Hi all [12:05] hello [12:05] jtv: just two revisions missing, actually [12:05] does anyone know that the download button on wide screens look bad ? [12:05] (the background image is not large enough) [12:06] asabil: thanks for the report... let me see if that's a known problem. [12:06] you're welcom [12:07] asabil: looks like that one's not known yet... could you file a bug against the "launchpad" project and attach a piece of screenshot to illustrate? [12:08] yeah sure [12:08] thanks [12:13] done: https://bugs.launchpad.net/launchpad/+bug/516000 [12:13] Bug #516000: The download button look bad on wide screens [12:17] asabil: great, thanks. The people who would normally deal with this are in a meeting this week, so it could be a while before somebody gets to it. [12:20] jtv, yeah sure [12:36] looks like lazr.config is used in the launchpad code [12:37] anyone knows if it supports variables substitution ? [12:39] asabil: it doesn't afaik [12:40] ok I see [12:40] thanks === mrevell is now known as mrevellunch [13:04] adiroiban, hi, sorry, in a live meeting here and get only short breaks from time to time :) [13:05] danilos: np. just ping me when you have more time. I want to know if I can continue with the implementation for some branches [13:05] adiroiban, anyway, I'd suggest you prepare an MP for 340664 and get it landed, it's still useful where it works [13:07] danilos: thanks. That is all for now [13:07] adiroiban, it was just a comment that we should definitely fix those performance problems as well (bug 475435) [13:07] Bug #475435: More timeouts on +templates page === mrevellunch is now known as mrevel === mrevel is now known as mrevell [13:46] Hi james_w, you mentioned in your email that you won't have time to continue the trigger work. I'm looking at continuing it (as I'll need the api exposure for some of the UI), but have a few questions. [13:46] First, is there any reason that you didn't land your approved branch here: https://code.edge.launchpad.net/~james-w/launchpad/create-source-recipe-build [13:49] And secondly, ah, I was going to ask about the inclusion of distroseries as an argument for requestBuild() (as defined on the iface), but then noticed that you haven't included it in the implementation? [13:50] which ever way your intention was, I'd be keen to hear the argument behind it (ie. whether a build should be able to define a distroseries different to the recipe). === jamalta-afk is now known as jamalta === salgado is now known as salgado-lunch [14:49] adeuring: btw, I forgot to list that I'm making screenshots for Jorge (today or maybe tomorrow) [14:49] kfogel: noted ;) [14:50] intellectronica: http://paste.ubuntu.com/367596/ has full results so far. How on earth can it not have terminated after more than eight hours?? [14:50] kfogel: because technology sucks? [14:51] intellectronica: oh [14:51] intellectronica: looking for failures now [14:51] sometimes our EC2 machines don't terminate. they have very strong will to live, i guess [14:51] it's worth looking at the mgmt console from time to time, because the costs can run very high if an instance is left running for many days [14:51] (i'm saying that from experience) [14:51] intellectronica: "Failure in test test_inline_request_a_reviewer (lp.code.windmill.tests.test_branchmergeproposal_review.TestRequestReview)" [14:52] intellectronica: *nod* [14:52] kfogel: i'd bet this is an unrelated spurious failure. we still get lots of those from windmill [14:52] let's try to run the same test locally to verify, but most likely that's the case [14:52] intellectronica: so, that failure appears after lots and lots of successes, including success of patches-view.txt. [14:52] okay [14:52] yay [14:53] intellectronica: how do I run a particular Windmill test? [14:53] kfogel: https://dev.launchpad.net/Windmill [14:53] * kfogel hides his head [14:53] intellectronica: thanks :-) [14:54] kfogel: crucial difference from the example is that it will be a different layer in this case. CodeWindmillLayer (iirc) [14:55] the windmill tests for each subdomain run in a separate layer, because of the restrictions browsers place on accessing JS code over different domains === matsubara is now known as matsubara-lunch [14:57] intellectronica: ah, gotcha [14:58] intellectronica: running now. Meanwhile, the EC2 test seems to be stuck at that spot -- there's been no more output, it just ends in the middle of a word.... [14:59] argh [14:59] happened before. guess you'll have to kill that machine and fire a new test run. [15:00] intellectronica: ok. well, I was going to have to re-run anyway, what with the DB patch coming up and possibly a few more changes from me due to mwhudson's review, so no loss really. [15:00] intellectronica: so test runs get stuck sometimes? This is not unheard of? [15:00] yeah, it happened to me before [15:01] oh goody, now my whole browser has frozen up [15:01] that's not unheard of either ;) [15:02] * kfogel snarkily observes that it never happens to him on his Debian box [15:02] Although, I don't do Launchpad development on my Debian box either, so it's under considerably less strain :-). [15:02] because it only runs lynx? :P [15:02] * intellectronica runs and hides [15:03] Yesterday I nearly shut down my whole Ubuntu laptop by running 'bzr log -v -n0 > outfile' in a devel branch. [15:04] OH [15:05] intellectronica: I didn't realize windmill tests actually display a browser dancing around! This is spooky. [15:06] kfogel: yes. there's also a way to run them headless, under xvfb. [15:06] but they have to run a browser to complete the test. that's the whole point of these tests - they interact with a real browser. [15:07] intellectronica: sure, I just didn't know that that browser displayed on the screen. [15:08] intellectronica: anyway, it passed [15:08] yes, for me too [15:10] intellectronica: okay, I'm terminating this instance in Elasticfox. Any reason I should show mercy? [15:10] intellectronica, ping, could you help confirm a JavaScript bug for me? [15:12] mars: sure. what's the problem? [15:12] when running launchpad, how can I disable the creation of the thread-*.request files ? [15:12] kfogel: no, you should feel free to terminate it if you've lost all hope of getting anything useful from that machine [15:16] intellectronica, try going to a bug on staging.launchpad.net, and edit the product. [15:16] intellectronica, when I do so I see an infinite spinner [15:16] mars: yes, we've seen this problem before [15:16] intellectronica, and if I have Firebug turned on to catch all errors, it does grab something [15:17] oh? [15:20] I can't make out the red error text though. It is hidden by the long line. [15:20] Maybe the error is also present in .dev [15:40] mars: sorry, back now [15:40] there's a bug already filed about this, let me try and find it [15:40] ok [15:41] oh, and i can reproduce on FF [15:43] mars: https://bugs.edge.launchpad.net/malone/+bug/443217 [15:43] Bug #443217: Changing a bug's affected project or description doesn't ever finish [15:44] adeuring: question about our "make_thing()" meta-factory function from patches-view.txt story tests. That function has now moved to factory.py, and is LaunchpadObjectFactor.doAsUser(). In https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428, Michael Hudson asks: "Do you really need to commit here? Zope-level users and database transactions are basically orthogonal." Full context at http://pas [15:44] te.ubuntu.com/367658/ [15:50] kfogel: yes, I think we must commit here. A story test does not access the database directly, but via a web server, which has its own database connection. When we manipulate the database via factroy.makeSomething(), the connetcion of the web server does not "see" any change, if we don't commit(). Also, I think we get an error message if we don't commit when the web server accesses the DB after a factory.mkeWhatever() call. Just re [15:51] adeuring: thanks. I'll respond to mwhudson with that. [15:54] adeuring, intellectronica: advice: I'd like to change the "package" column to be called "target" in the patches view, because sometimes it's a package and sometimes it's a product (e.g., if you show the patches view on a project group). [15:54] Thoughts? [15:54] kfogel: sounds good. But there is another option, ii think [15:54] ? [15:55] you can display "package", if the context is a distribution or distroseries, [15:55] and you can display "project" if the context is a project group [15:55] kfogel: wouldn't it be better to title it dynamically, depending on what kind of target it is? i don't think we use 'target' anywhere in the UI. [15:55] adeuring: high five! [15:56] kfogel, intellectronica: though things will become messy with this approach when we have a patches view for persons... [15:57] kfogel: ignoring the IPersoncontext, you could get the right column name for the current context from a browser class property. [15:57] adeuring, intellectronica: So here's why I didn't propose the conditional solution: is it possible that the same view (same column) may display multiple types of targets? [15:58] kfogel: yeah, now you mention this... [15:58] if we have a bug with emough targets, that will happen... [15:58] e.g., a bug where target 1 is a package and target 2 is a project [15:59] but don't we only deal with one target at a time? [15:59] adeuring: well, it's not a matter of quantity, it's just that it could happen -- heck, maybe I could make it happen right now with project group, by attaching a bugtask to a package in a project in that group? [15:59] kfogel: sure [15:59] intellectronica: let me see if I can actually make this happen here [15:59] i mean, doesn't the patches view filter only bug tasks for a single target (unless it's a distro)? [16:00] intellectronica: distro, or project group,... [16:00] intellectronica: but distros are the context where we need this "target/"Pakcages" column... [16:00] intellectronica: and when the view is on a product, then it shows different src packages [16:00] in fact, maybe you also want to hide that column if it's not a distro or a project group [16:00]