=== Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad [01:32] Gooooooooooooooood morning Launchpadders! === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad [01:34] morning mpt [01:34] will you do a patch for bugtask-index for me :-) === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === mpt reads kiko-zzz's message [02:04] mpt, mpt, mpt [02:07] hmm [02:07] So you want me to reply here instead of USING E-MAIL? :-) [02:08] no [02:08] I want you to reply using bzr commit! [02:08] ok [02:09] What do you think of the idea of renaming tags as categories? That could reduce their overuse [02:10] mpt, interesting idea, but why would it reduce its overuse? [02:14] kiko-zzz, because more people would realize that tags like "biometric", "hide", "hot", "key" etc aren't useful [02:14] heh, perhaps. but perhaps biometric is useful. :) [02:14] anyway I'll sleep on it if you send me bzr commits :-) [02:14] night [02:14] goodnight [02:15] BjornT, have you seen tag clouds? === rpedro [n=rpedro@87-196-69-6.net.novis.pt] has joined #launchpad [02:48] lifeless, ping [02:49] pong [02:53] lifeless, would it have been very difficult to get PQM to accept devpad as well as sodium, rather than instead of? [02:53] yes [02:53] ok [02:53] it would have been 'write new code' rather than 'change a config file' [02:54] It's just that the idea of devpad was to *reduce* hostname churn :-) [02:54] and its now reduced [02:54] the next relocation will not involve changing the hostname - devpad.canonical.com will stay [02:55] 'Course, now that we've done that, sodium will probably be obstinately permanent ... [02:57] NMP :) [03:30] braaaains === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad [04:36] ugh, https://launchpad.net/products/arun.c.k [04:40] that looks a bit out of place === geforcex [n=geforcex@220.202.38.131] has joined #launchpad === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad === lakin [n=lakin@S01060013101832ce.cg.shawcable.net] has joined #launchpad === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === rpedro [n=rpedro@87-196-77-251.net.novis.pt] has joined #launchpad === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad [07:50] mpt: no, i don't think i've seen tag clouds. what's that? === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad [08:05] spiv, ping === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad === carlos [n=carlos@13.Red-88-16-33.dynamicIP.rima-tde.net] has joined #launchpad [08:12] morning [08:15] hi carlos [08:15] carlos, have you successfully submitted a merge into devpad yet? [08:15] not yet [08:15] mpt: do you have problems? [08:16] carlos, yes, bzr pqm-submit tries to merge into bazaar-ng.org/bzr/bzr.dev [08:17] what do you have at .bazaar/branches.conf ? [08:18] Exactly as written in , but with all "sodium.ubuntu.com" changed to "devpad.canonical.com" [08:20] mpt: did you try the --dry-run option ? [08:20] to see what's being send [08:20] yes, that's how I found out it was trying to merge into bazaar-ng.org [08:21] ok, last check [08:21] do you use 'bzr push' to push your branch ? [08:21] yes [08:21] that's the problem then [08:22] edit branches.conf and remove the concrete section for the branch you try to merge [08:22] I shouldn't be using bzr push?? [08:22] it's a bug [08:22] mpt: bzr push adds a new section specific for the branch you push [08:22] yes, I noticed that [08:23] then, pqm-submit sees it and doesn't look for the shared repository info [08:23] oh [08:23] just remove it and try again [08:23] hmmm, that's going to suck until the bug is fixed :-) [08:23] ok [08:23] brb === mpt [n=mpt@ip-58-28-158-74.ubs-dsl.xnet.co.nz] has joined #launchpad [08:25] carlos, that gives me "bzr: ERROR: Not a branch: sftp://devpad.canonical.com/home/warthogs/archives/mpt/launchpad/.bzr/branch/" [08:26] hmmm [08:27] btw, the bug should be fixed soon [08:27] if it's not already fixed [08:27] I tried re-pulling the pqm-submit plug-in, but there were no new revisions [08:28] mpt: did you see that the repository changed ? (I think lifeless said that a couple of weeks ago) [08:28] mpt: from where are you sending the submit request? [08:29] mpt@canonical [08:30] I need to go home now, I'll mail the list about it [08:30] Thanks for your help carlos [08:30] mpt: ok. Btw, I mean the directory ;-) [08:31] I remember there was some discussion about using a /code directory [08:31] but I didn't see any decision about it, and the WorkingWithSharedRepositories page hasn't been updated [08:31] well, I don't think it's the problem [08:32] anyway, tchau [08:32] What I want to know is if you sent the merge request from withing the working tree of your branch [08:32] or from the repository [08:32] he left... ;-) === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos will be back in 30 minutes [09:55] later === jamesh [n=james@82.109.136.116] has joined #launchpad === matsubara [n=matsubar@82.109.136.116] has joined #launchpad === niemeyer [n=niemeyer@82.109.136.116] has joined #launchpad [10:18] morning === mpt [n=mpt@210-55-43-171.dialup.xtra.co.nz] has joined #launchpad === carlos [n=carlos@62.87.60.100] has joined #launchpad === stub [n=stub@82.109.136.116] has joined #launchpad === dsas [n=dean@host86-129-22-110.range86-129.btcentralplus.com] has joined #launchpad === Techno [n=adrielk@210-246-50-136.paradise.net.nz] has joined #launchpad === Techno [n=adrielk@210-246-50-136.paradise.net.nz] has left #launchpad [] === Fujitsu [n=Fujitsu@c58-107-168-5.eburwd7.vic.optusnet.com.au] has joined #launchpad === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad [11:05] carlos: ping [11:05] danilos: pong === doko [n=doko@dslb-088-073-074-120.pools.arcor-ip.net] has joined #launchpad [11:12] danilos: ? === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:15] Good morning [11:15] carlos: sorry, wanted to know what happened with our daily 10am meetings? [11:15] carlos: also wanted to see if we're to do RosettaHighlights one of these days? :) [11:16] danilos: well, I forgot them after the vacations... :-P [11:16] rosettahighlights? [11:17] carlos: you naughty, naughty boy :) [11:17] ddaa: morning === carlos hides [11:17] carlos: like malonehightlights, see the mark's mail on list :) [11:17] danilos: I'm a bit behind with mailing lists... [11:18] ddaa: morning, did sauna feel nice this morning? :) [11:18] carlos: ok, never mind that then :) [11:18] Ta, Y [11:18] I'm not in a hotel now [11:18] carlos: I can then do that, and will let you go over it and correct everything :) [11:19] so I do not have any "fitness center" facility to enjoy close enough to be bothered [11:19] ddaa: you don't have one home? :P [11:19] danilos: go ahead, please [11:19] danilos: there are probably saunas as large as my whole appartment === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [11:22] ddaa: :) [11:31] stub: ping [11:32] carlos: pong [11:32] stub: about your review [11:33] the script I wrote is just to migrate translations from breezy to dapper, after that, the opening of a new distrorelease is called from the initializeFromParent method that is called to copy soyuz data too [11:34] so that script will be removed [11:34] should I change that? [11:35] or the soyuz copy also needs to shutdown launchpad? [11:52] stub: ? [11:55] We can't afford to do this operation without downtime [11:55] What calls initializeFromParent? [11:55] carlos: ^^^ [11:57] stub: a script that is executed to open a new distrorelease [11:57] let me lock for it [11:58] stub: scripts/ftpmaster-tools/initialise-from-parent.py [12:36] carlos: Ok. So the verbosity issues apply to that script too - we can't run that script without downtime. [12:36] stub: should I file a bug against soyuz? [12:37] And we want to monitor what it is doing. [12:37] carlos: If your code just prints to stdout, that should be good enough. [12:37] Or uses the standard script logging would be better [12:37] (not necessarily the actual SQL - just a notice on what step is being performed. [12:38] We can look up the SQL in the source code if we care, or interrogate postgres for that info) [12:45] gandwana app servers are going down for some testing [12:49] stub: ok [12:49] thanks === carlos -> out [12:49] I will be back in 30 minutes or so === danilos [n=danilo@82.117.204.79] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === mpt [n=mpt@210-54-233-45.jetstart.xtra.co.nz] has joined #launchpad === glatzor [n=sebi@ppp-62-245-210-231.dynamic.mnet-online.de] has joined #launchpad === danilos [n=danilo@82.117.204.79] has joined #launchpad === danilos [n=danilo@82.117.204.79] has joined #launchpad === danilos [n=danilo@82.117.204.79] has joined #launchpad === danilos [n=danilo@82.117.204.79] has joined #launchpad === mpt [n=mpt@210-55-179-98.dialup.xtra.co.nz] has joined #launchpad === carlos [n=carlos@13.Red-88-16-33.dynamicIP.rima-tde.net] has joined #launchpad === carlos -> lunch === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [02:16] re === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === jsgotangco_ [n=jsg123@125.212.14.190] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:11] morning flacoste [03:11] morning salgado! [03:12] flacoste, I was planning to work on karma for the support tracker. are you working on something that could conflict with that? === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [03:13] salgado: are you using events to assign karma? [03:15] flacoste, in some cases we use, but not always. I haven't yet checked what will be the case in the support tracker, but it's possible that I'd have to use them [03:16] salgado: well, i'm working on the +linkbug, +unlinkbug views, there are also changes to the addview that are pending reviews [03:18] hmmm. okay. I don't expect my changes will be too intrusive, so I think it'd be okay for me to solve these conflicts later [03:30] morning salgado , flacoste [03:30] morning sivang [03:30] hey sivang [03:34] hey salgado , I recerntly looked in our photos from Montreal, I remembered how fun it was on the mountain :-) [03:35] indeed, that was a lot of fun! :) [03:42] salgado: I especially liked the weather :p [03:42] I have to admit that wasn't what I liked the most --too cold for me [03:45] I recall you too were cold, but I was too hot since I was in very bad shape and it was hard following you guys when you were jumping gracefully from on the way up :-) [03:46] It was a real excersize [03:48] is pqm known under maintenance ATM? [03:48] blah [03:49] ddaa.attention_level = None [03:49] AttributeError [03:57] mmmmmmmmmmmmm [03:58] is that the groan of the kiko in the morning? === dholbach [n=daniel@ubuntu/member/dholbach] has joined #launchpad [03:58] I am not feeling super today [03:58] hellas! can we have a top10 of top contributors on lp.net frontpage? :) [03:58] so watch out! [03:59] I'm not afraid, I can be more grumpy than you! [03:59] dholbach, we'll have that soon. for now what we have is http://staging.launchpad.net/distros/ubuntu/+topcontributors [03:59] I'd like to know if there's somebody else between Kamion and me ... karma-wise :) [03:59] ooooooh *looks* === mdke notes dholbach is *way* bacl [04:00] s/bacl/back [04:00] hmm. 3 people between you and Kamion [04:00] the points are not in sync with the lp page, are they? [04:01] kiko: to relax in the morning, you may try re-reviewing bug-44860 branch :P [04:01] they should be one or two days old at most, I think [04:01] hm ok [04:01] danilos, yeah, today is review day. === matsubara [n=matsubar@82.109.136.116] has joined #launchpad [04:01] salgado, why are they old? [04:02] dholbach, I have to note that we only started tracking the context (product/distribution) two weeks ago, that's why the 'Distribution Karma' is so much less than the 'Total Karma'; that is, for most of the karma we have, we don't know to what product/distribution it refers [04:03] kiko, because it's staging and I don't know when it was last synced [04:03] salgado: ok [04:03] oh, staging [04:03] good === niemeyer [n=niemeyer@82.109.136.116] has joined #launchpad [04:03] I just thought I had missed a rollout. :) [04:03] kiko: hope you enjoy reviewing it as much as I did writing it :) [04:07] salgado, ping? [04:07] kiko, pong [04:07] salgado, so I note an oddity related to wikis [04:08] https://staging.launchpad.net/people/gnome-l10n-ku [04:08] https://staging.launchpad.net/people/goodgerster [04:08] salgado, the wikinames listed have dupes. any clue why? [04:09] they're for different wikis? === stub [n=stub@82.109.136.116] has joined #launchpad [04:09] salgado, ah! [04:09] man that's confusing! [04:10] the wikis could use emblems [04:14] yo kiko [04:14] Spads, we don't have icons for the wikis though === Spads nods === SteveA [n=steve@82.109.136.116] has joined #launchpad [04:16] hi SteveA [04:16] hi sivan [04:50] kiko, will you have time to review that shipit branch this week or maybe I should move it to the general queue? [04:51] salgado, I will have time. [05:02] BjornT: ping [05:02] kiko: did you see my email about the Fridge the other day? any views? [05:02] hi bradb [05:02] mdke, I'm happy to post there, though I saw somebody saying that the highlights needed to be heavily edite [05:02] d [05:03] BjornT: oh, unrelated to what I was going to ask you, I just changed the status of bug 6759 and got a newbug notification [05:03] Malone bug 6759 in malone "filtering bugs with no upstream filed / blocked on upstream" [Medium,In progress] http://launchpad.net/bugs/6759 [05:03] i noticed a similar problem yesterday [05:03] i think this might be a known problem. ring any bells? [05:04] kiko, I think something similar to the highlights you wrote on the last edition would do fine. Do you intend to continue doing that? [05:04] mdke, I do. if so, then great, I'm happy to post there [05:04] bradb: there's a bug about it, you even reported it yourself once, think :) [05:04] right, anyway, back to my original problem [05:05] BjornT: any reason why the upstream status search UI isn't included on person advanced search? [05:05] kiko: I suppose the last edition's highlights might be a bit long for a normal fridge article, but that may just be because it was a very large edition. [05:06] it was very long [05:06] i think you can exercise your own judgment, I'll make an account for you [05:07] kiko, cprov: Do you know offhand which tables we need to sortable on debian version? [05:07] stub, I know sourcepackagerelease, binarypackagerelease, distrorelease at least. [05:07] distrorelase?? [05:08] stub, amazingly so. look at distrorelease.py [05:08] you're using debian sorting algorithm for distro versions? [05:08] Why on earth would a distrorelease have a debian version number? I suspect it is just a version number [05:08] or hmmm [05:08] stub: in fact, SPP/BPP, which are SQL view, would it be possible ? [05:09] cprov: If I create indexes on the underlying tables that should work. [05:09] kiko: if you can join ubuntu-fridge on LP, that helps us keep track of who has an account, and will work well for when the fridge uses LP authentication ;) [05:09] stub: great ! [05:09] mdke, okay,will join now [05:10] mdke, applied. [05:11] mdke, ubuntu-fridge needs an emblem!!11! [05:11] how safe is it to send passwords over launchpad team approval email? [05:11] stub, I could swear we compared distrorelease versions using apt_pkg, but.. [05:11] mdke, passwords? [05:12] bradb: hmm, can't remember why it isn't included on the person advanced search. i don't see any reason why it shouldn't be. [05:12] aha! [05:12] I suppose it depends on the sensitivity of the password huh [05:12] stub, see distribution.py -- it uses sourcerer.deb.version to sort releases. [05:13] Ok. No point creating an index though since we only have a handful of distroreleases [05:13] stub, AGREED. :) [05:13] BjornT: and yet it shows on the upstream bug search page! ;) [05:13] i'll fix those issue while i'm in the neighbourhood today [05:13] bradb, the dude! === bradb has been meaning to watch TBL [05:15] bradb: The Black Lotus? [05:15] The Big Lebowski! [05:15] doh! [05:15] there goes my irc-as-a-stack reading habit again [05:16] bradb: oh man, that movie is SO rad [05:16] bradb: I've watched it a dozen of times at least [05:17] bradb: well, it does make sense on the *product* bug search page. for example zope and sqlobject are upstream to launchpad. [05:18] BjornT: I'm not sure I agree, because AFAIK, our model can't capture that. "Upstream" in this context really means products, AIUI. [05:18] feel free to explain why I'm wrong though [05:19] i'd be even more blown away if it turns out the current search would actually /work/ for that case right now! [05:19] bradb, it should probably work, but then the word "Upstream" doesn't :) it would be "other products" [05:20] LarstiQ: the black lotus! and the Mox Pearl! [05:20] dholbach: I was thinking of the demo group though :) [05:20] LarstiQ: who cares of the demo group if you have 5 moxes and a black lotus! :-p [05:20] kiko: how should it work? are you saying that our model/UI knows how to capture that zope and sqlobject are upstream to Launchpad? [05:21] bradb: so are you saying that when searching for an 'upstream status', we shouldn't search debian bugs, since debian isn't a product? [05:21] bradb, no, no. [05:21] dholbach: they don't run on my amiga! [05:21] BjornT, right. we can't currently do that. [05:21] dholbach: http://pouet.net/prod.php?which=25778 for instance [05:21] BjornT: that's what i'm saying [05:21] BjornT, well, we can, but the word "upstream" won't work. [05:21] the reason I say that [05:21] is that say you have a bug with ubuntu and debian tasks [05:22] you can go to ubuntu [05:22] and query for "upstream" tasks [05:22] and it would return debian [05:22] you can also go to debian [05:22] and query for 'upstream' tasks [05:22] and it would return ubuntu [05:22] now ubuntu is not upstream to debian [05:22] but we have no way of telling the situations apart in our data model [05:22] yeah, i know, that's why i labeled it 'status elsewhere' at first [05:22] upstream to us means products [05:22] right. [05:22] kiko: on a per package basis it might be? [05:23] LarstiQ? [05:23] LarstiQ: http://en.wikipedia.org/wiki/Power_Nine#Black_Lotus - but i now better shut up before i get smacked [05:24] kiko: OTOH, we do use a "(upstream)" suffix for affected products [05:24] bradb, not OTOH -- it's the same hand. upstream for us is products! [05:24] kiko: for a particular package, debian can be getting it from ubuntu rather than the other way around [05:24] kiko, cprov: I'm landing gustavo's debversion helper so you can sort by debversion in the db. I've created indexes on sourcepackagerelease and binarypackagerelease too to make this sorting fast (probably - I might need to tweak the indexes if your queries are particularly pathalogical) [05:24] bradb, I was making a case for not saying "upstream" when we mean the relative association between OSS things. [05:24] yeah, i know [05:25] what i'm getting at is that, currently, both product and upstream are confusing words for the search ui [05:25] stub, you're amazing! thanks! [05:25] woo this will be excellent [05:25] really help memory usage and perf for searches [05:25] stub: comment, the bug in question, I will try some tests ASAP. Thanks you, dude ! [05:26] both terms are assuming things about users. 1. "product" assumes that people know that "products" are not sps/distros/etc. 2. "upstream" makes a rough estimate that when you say "upstream", you're thinking distro -> product. [05:27] at this point in lp's life, i think one option is really no more correct than the other. if they were 15 distros actively collaborating in lp right now, i'd probably think differently. [05:28] bradb: do you have some suggestion of what to name it instead? you were the one that suggested 'upstream status' in the first place. [05:28] i'm suggesting staying with "upstream status". it's a rough estimate right now, but i don't see another option that is clearly a better alternative, atm. [05:29] we may learn that it's wrong, and then it's easy to change [05:29] what's this padlock symbol against email addresses? [05:30] and i suggest it not be shown on our current product bugs adv. search form, because i don't think that can make sense atm, no matter how we word it [05:30] I'm told it means "private email address" [05:30] kiko, BjornT: thoughts? [05:30] but I don't see how a padlock indicates privacy [05:31] the padlock is also what we use to indicate privacy for bugs [05:32] bradb, either upstream == product or use the text "elsewhere" and search through any other context's bugtasks. [05:32] (I'm not arguing I think it indicates privacy, though) [05:32] bradb, kiko: personally i'd go for 'status elsewhere'. [05:32] SteveA, that padlock was added as part of your request, fwiw [05:32] did I specify a *padlock* >? [05:32] SteveA, only admins and the user himself can see that [05:32] I must have been on crack [05:32] SteveA, no, you didn't, and if you have a better icon, provide me with one, otherwise, booo :-) [05:34] I think a padlock is a good way to evocate secrecy. [05:35] thank you ddaa [05:35] Everybody is familiar with that from https [05:35] not everyone understands even https [05:35] SteveA, by the way, you reviewed that patch. it is r=SteveA. :-P [05:36] kiko, BjornT: I think "product" is as likely to be misinterpreted as "upstream", but, since it's easy to change, I'll willing to give it a try. i'd prefer not to do "status elsewhere", because it was the distro -> upstream product which this feature was designed for [05:36] s/I'll/I'm/ [05:36] kiko: I'll take a photo of the "do not disturb" sign you can put on your door at the hotel [05:37] kiko, bradb: how about something like 'Status in: [ ] ', where you can type in what you want to search on, either a distribution, or a product. [05:37] BjornT, that won't work, distro bugs can be part of a number of upstreams. [05:38] bradb, okay, if you think the feature won't work for other contexts as easily, I'm fine with upstream or product. [05:38] kiko: well, i was thinking of having something to say 'any other product or distribution' as well. [05:38] stub: mail sent [05:39] kiko: this one will do: http://images.google.com/images?q=+privacy+holtzspa [05:39] BjornT, we can do that, but I don't think it needs to be done now [05:39] BjornT, otherwise we're stretching bradb's branch [05:39] BjornT: the only clear use case we've seen so far is to get a list of all bugs that need to be forwarded upstream, might need forwarding upstream, have fixes available upstream, etc. though not for a specific product [05:39] indeed. i'd prefer to do as little as possible [05:40] sabdfl: So according to your email, you can't merge rocketfuel into that branch? [05:40] SteveA, sabdfl: do I need to reply to gward's latest email? === stub wonders how landing will work === SteveA looks [05:40] kiko: did you just forward it? [05:40] bradb: fixes available in debian is a use case as well. [05:40] stub: i can, but if you also commit, then i have to delete my patch, and i would rather you modified my patch in a place i can merge from [05:41] It is already in rocketfuel [05:41] can you please not do that again? [05:41] Sure. I just don't understand what the problem is. [05:41] say i wanted to tweak column names [05:41] SteveA, no, it went to the launchpad list [05:41] i would have to merge two unrelated files in bzr [05:41] kiko: how long ago? [05:41] we have an expensive rcs just for this [05:41] BjornT: I think the strongest use case is just "Fix available" [05:42] SteveA, a few hours [05:42] kiko: I seem to be missing it [05:42] sabdfl: patch is here: https://sodium.ubuntu.com/~andrew/paste/fileuwGw9q.html [05:42] bradb: agreed, just as long as debian bugs are included there. [05:42] stub: that's rather not the point [05:42] sabdfl: If you want to tweak column names, then it would need a new review anyway. [05:42] sent. [05:43] sabdfl: Which would indicate you asked for a review too early. [05:43] stub: nonetheless, please do not commit alternate version of the same file [05:43] sabdfl, I don't get it. if stub's merged your branch and it went to RF, when you merge RF you'll just pick up the new revisions [05:43] kiko: he never merged my branch [05:43] oh was the file renamed? [05:43] he just committed a new file [05:43] I didn't merge marks branch, so one revision would need to be removed. [05:43] ah I see [05:43] with a different name [05:43] ah right. [05:43] yeah that kinda fucks up the rcs [05:43] and no history [05:43] in fact, stub please delete that file [05:44] is it in RF already? [05:44] i have a series of changes committed, and each of them is tied to having the right version of that file [05:44] if so just merge RF and copy the file over and delete it [05:44] kiko: I'll reply to you with my comments [05:44] kiko: no [05:44] stub, please fix this [05:44] then your old file history is preserved and you nuke out the new file === kiko shrugs [05:44] SteveA, oookay [05:46] bradb: in bugtask-macros-tableview, there is a an table macro that seems to fit my purpose but it doesn't seem to be used anywhere else: should I use it? [05:46] flacoste: which macro? [05:46] bradb: 'table' [05:47] bradb: only advanced_search_form seems to be used, the other ones 'btached-table', 'item' are defined but not used [05:47] bradb: at least according to grep '+bugtask-macros-tableview' templates/* [05:48] kiko: he seems happy that you were responsive to his queries [05:48] SteveA, yeah. he didn't ask me anything this time around though [05:49] flacoste: I need to clean those up (more than all the crap I had already deleted), so that it's clear what's usable and what's not. why not use the same kind of listing we currently use for listing bugs? [05:49] with batching, etc [05:49] bradb: because I need the 'select' column [05:50] bradb: i.e. add a checkbox to each row [05:50] yeah [05:50] brabd: which the other listing in use doesn't have [05:51] flacoste: it would be more beneficial, i think, to improve the code we're using to suit your use case, than to reach into the dark and neglected bits [05:52] because we have a use for a checkbox in Malone too [05:52] what do you think? [05:53] bradb: I agree that it's better to reuse what is used elsewhere [05:53] bradb: i can take care of adding the checkbox, do you have an idea of how you would like to see this done? [05:53] bugs-listing-table.pt is the meat of it, and includes a way of showing/hiding columns on demand [05:54] e.g. [05:54] bradb: yep, I've look at that file [05:55] bradb: what do you think if I put an empty slot at the beginning of each data row? [05:56] flacoste: i'd say show a column with a checkbox, if needed, otherwise don't show that column [05:56] an empty slot adds no value to the UI [05:57] if you're feeling frisky, you could even refactor it to "context/shouldShowPackageName" [05:57] bradb: i agree its kind of a hack, but the problem I see is that I think the checkbox will need customization for each case (to integrate with the view that process the submit) [05:58] bradb: i'll pass the context/shouldShowPackageName refactoring for now, there is already enough stuff on my branch :-) === seb128_ [n=seb128@ANancy-151-1-5-177.w83-194.abo.wanadoo.fr] has joined #launchpad [05:59] flacoste: if it's just a cb for selecting a bug, it should be reusable everywhere. the cb needs no context-sensitive naming [06:00] bradb: hmm, i kind of disagree with that, think of it as a reusable widget, widget have context sensitive naming so that part of the macro should also have [06:01] i can't think of various generic uses for such a thing: tagging, approving/declining nominations for a specific release, mass editing, etc. i can't think of why I'd want to call the cb something other than, say, "selected_bug_id", or something, for all those completely different use cases. [06:01] that is, i /can/ think of various generic uses, of course [06:02] bradb: ok, i'm overengineering, in /my/ case, I can live with the selected_bug_id name, so I'll do that [06:02] carlos, do you know when we will move the translation focus to edgy? [06:02] flacoste: cool [06:02] bradb: when that name won't work, we'll refactor then [06:03] good call [06:03] danilos[out] ^^^ [06:03] bradb: should I put a header on that checkbox column or just extend the Summary colspan? === flacoste votes for extending the colspan === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad [06:05] flacoste: you could just render a cb to the left of the bug icon. no extra td even needed. [06:06] bradb: fine [06:06] bradb: other question: what about the checkbox label: should I wrap the title in a label tag? [06:07] hm, good question [06:07] bradb: the label is neat for testbrowser: browser.getControl('Firefox crashes').selected = True [06:09] i'm just pondering which of, say, the bug icon, bug id, and title should be labels [06:09] maybe none, maybe all [06:10] all would be problematic: they are in different td [06:10] kiko: I got the approval from stuart to merge my changes to open Edgy [06:10] you'd have to use for id notation [06:10] as soon as we execute the script to open Edgy, we can change it [06:11] bradb: no i mean, the id, icon and title are all in different tds, i can wrap them in one label element [06:11] carlos, what was needed to change in the code to support edgy? This is surprising -- I didn't see any email on the subjet at all [06:11] s/can/can't/ [06:11] kiko: the migration from breezy to dapper and the migration from dapper to edgy [06:11] flacoste: yeah, i know, that's why i'm saying you'd have to use the for="id" notation [06:11] kiko: so we reuse translations only in Rosetta [06:11] [06:12] kiko: that was our main task in London last sprint [06:12] carlos, did we never migrate from breezy to dapper? [06:12] no [06:12] oh [06:12] bradb: but td can't nest in label [06:12] hmmm [06:12] I would have appreciated email on it. is there a spec? [06:12] bradb: and is there another way then the for attribute to link a label to its control? [06:13] flacoste: [06:13] bradb: you sure that would work? [06:13] kiko: I had a preimplementation call with spiv about it [06:13] kiko: in fact, you complained about the solution [06:13] kiko: so you read it ;-) [06:13] bradb: with testbrowser I mean, i'm not sure you can have more than one label by control [06:13] yeah I remember [06:13] flacoste: not 100% sure, no. the only two ways i know offhand to link labels with controls are for="id" and wrapping the widget in the label tag [06:13] but I only read it highlevel and didn't know what the real problem was [06:14] carlos, so no spec or email? that's really bad [06:14] flacoste: but i would surprised if multiple labels for the same id didn't work [06:14] flacoste: if testbrowser can't handle more than one label per control, it's a bug, please report it if that's the case. [06:15] kiko: well, as I already told you when we sent the preimplementation call summary, the approach is more or less the same soyuz took to open a new distrorelease [06:15] I guess a concrete spec would be better [06:15] or even email [06:15] explaining the problem [06:15] flacoste: but anyway, as for what's best to labelize, your guess is probably as good as mine, but mpt's guess is probably better than both of ours [06:15] I mean I don't expect heavyweight anything for everything [06:16] but I hope people bring up the issues via email as they appear [06:16] flacoste: i'd probably labelize the icon, id, and title, but i'm not sure if that's the best way or not [06:18] bradb, flacoste: why labelize the title? it's a link anyway, so the user can't click on it in order to select the bug. [06:18] BjornT: flacoste suggested it for testing [06:18] i.e. with testbrowser [06:18] BjornT: browser.getControl('Firefox crashes').selected = True [06:19] flacoste: or even, browser.getControl(firefox_crashes.title).selected = True [06:19] but either are probably god [06:19] and good [06:19] bradb, flacoste: well, testbrowser is supposed to simulate a user using a browser. if the user would click on the id, why not do the same in testbrowser tests? [06:21] BjornT: well, it's just that I think that 'Firefox crashes' is more meaningful than browser.getControl('1').selected = True [06:21] but I won't fight untill death over that [06:22] BjornT: and I agree, that since the title is already a link, it has less value as a label [06:22] so I think the bug id and icon could be labels === flacoste will do a quick test to confirm that two labels for one element are at least supported by firefox beforehand === bradb is continually amazed that Safari doesn't even support labels [06:23] that means that konq shouldn't support either... === flacoste reports that it works in Firefox === flacoste will implement that form after lunch === malcc [n=malcolmc@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad === kiko winks at ddaa [06:38] :) [06:38] good man. [06:43] BjornT, how much work to make tags work across a project? [06:48] kiko: what do you mean? [06:50] BjornT, well, to be able to search for field.tag on /projects/launchpad/+bugs [06:51] oh [06:51] it already works! [06:51] BjornT, rock on! [06:51] :) [06:52] BjornT: major, major brownie points there, i think [06:53] heh === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad [07:18] stub: hi, around? [07:18] carlos: yes [07:19] stub: I'm not able to do a rollout on staging of my latest changes because seems like there is a dead connection from mawson [07:19] that is loking the database [07:19] s/loking/locking/ [07:20] stub: but I don't see anything on mawson that looks like a connection to asuka [07:21] carlos: fixed [07:21] stub: thanks [07:23] staging is back ;-) === bradb & # lunch === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === steveire [n=steveire@unaffiliated/steveire] has joined #launchpad [07:45] Has anyone had shipit cds sent to germany and how long might it take? [07:47] Also, is it possible that I can change the destination for the cds if they don't arrive before I leave? [07:48] steveire, have they already been shipped? [07:48] steveire, they usually take around 6 weeks to deliver. might be faster to germany, though [07:48] Can I tell from the launchpad site if they have or not? [07:49] I can't remember the date I ordered them but I think it was two weeks ago. I'm moving in two weeks though [07:50] steveire, then it's probably shipped already, and it's not possible to change the shipping address [07:50] steveire, on https://shipit.ubuntu.com you should be able to see the date it was sent to the shipping company [07:51] 10 CDs requested in 2006-07-25. 10 CDs approved and sent to the shipping company in 2006-07-25 [07:51] where do they get shipped from? Is there one source or several? [07:52] Netherlands, IIRC [07:54] alright, cool. I'll see what happens. Thanks for the info. [07:55] np === kalosaurusrex [n=aaron@dhcp59190.vcd.hp.com] has joined #launchpad [08:05] kalosaurusrex: hi [08:08] SteveA, do you approve my codeofconduct tag? [08:09] kiko: the meeting is tomorrow. i haven't looked. [08:09] oh, they are only approved at meetings? I did not know. [08:09] is it urgent? [08:09] nope. [08:09] I'm already using it :) [08:09] i'm about to get together with gustavo and write up the widget refactoring to take over the world [08:09] whoa! [08:09] that's great to hear [08:09] it is rad [08:10] make it kick butt [08:17] stub, ping [08:17] kiko: pong [08:17] stub, https://launchpad.net/products/malone/+bug/29227 [08:17] Malone bug 29227 in malone "Searching for "pmu" doesn't find "/dev/pmu"" [High,In progress] [08:17] stub, fixed released, right? [08:18] No [08:18] it works now [08:18] stub? [08:18] How odd. Please leave it open - I expect it is working by accident [08:18] ok. === steveire [n=steveire@unaffiliated/steveire] has left #launchpad ["Konversation] [08:20] SteveA: are you extending the base zope3 widget or will it be a completely different framework? [08:20] it will be much much simpler [08:20] but *may* be compatible with zope widgets via a wrapper [08:20] we'll see about that [08:21] do you intend to keep the binding of widget to field via adapters or is it the removal of that part that will make it simpler? [08:23] kiko: I've got some updates to the LaunchpadFormView class to let us address the tabindex problem [08:23] kiko: there is also support for overriding a particular widget's error from the form-wide validation method [08:24] jamesh, I saw your bug comment -- very neat! [08:24] carlos, https://launchpad.net/products/rosetta/+bug/2022 -- ? [08:24] Malone bug 2022 in rosetta "iso-codes is not available for breezy" [High,Confirmed] [08:32] salgado, stub: I just had an ingenious idea: instead of nuking products, /merging/ products! [08:32] salgado, stub: that would handle all the use cases I can think of, and would solve the problem of things going invisible or being destroyed [08:33] What use cases are you trying to solve? [08:33] stub, product deletion and product 'migration' [08:33] we could delete products by merging them with a graveyard product [08:33] I don't see how it helps product deletion. Migration and merging incorrectly displayed products, yes. [08:34] and we could then make the graveyard product be admins-accessible only or whatever [08:34] well, there's the idea anyway. [08:34] Why have a graveyard product? Why not just flag the product as inactive? [08:34] stub, well, mostly because it makes any link to the product (which can come from many places) break. [08:35] whereas with a merged product those links would be updated [08:35] Why would that not be the case for a graveyard product too? [08:35] we'd need to special case the graveyard product everywhere, no? [08:35] stub, the product would still be around, but it would be one product instead of 100 products being deleted. [08:35] isn't that the same as special casing inactive products? [08:35] salgado, we could if we wanted to, but it wouldn't be necessary. [08:35] we could still allow traversal to it [08:36] I mean "wouldn't ne /necessary/" [08:36] as part of the solution [08:36] For the 'delete my product' use case, I think we want to improve the behavior of inactive products rather than lose information by merging with a graveyard product. [08:36] In particular, if we merge to a graveyard product we have no way of undoing the operation. [08:36] the only thing you lose is the name of the original product.. [08:37] that is true. [08:37] I'm not sure if it would screw up the supermirror either. [08:37] but I hate to see the dozens of bogus products registered === sebastienserre [n=sebastie@AVelizy-155-1-30-145.w81-249.abo.wanadoo.fr] has left #launchpad ["Ex-Chat"] [08:37] and not be able to do it [08:37] (but merging would be good for other use cases) [08:37] do anything [08:37] So flag them as inactive. [08:38] hmmm. [08:38] maybe I should try and tell you how that worked out. :) [08:39] freeCD [08:39] ubuntu [08:39] Registered by arun.c.k on 2006-08-08 [08:39] stub, one thing I'm concerned about flagging it as inactive is that I don't know how much will break [08:39] stub/kiko: merging products could lead to branch name collisions [08:39] whereas with merging I know -- nothing will. [08:40] ha! === dholbach [n=daniel@ubuntu/member/dholbach] has left #launchpad ["Ex-Chat"] [08:40] jamesh, well, the branches would need to be renamed, yes. [08:40] So you want to add new features to avoid finding possible bugs in existing features? [08:40] stub, I think the active/inactive feature is just a lot harder to get right. [08:41] a product now has a series related to it to.. ugh [08:41] kiko: we'd shake bugs out of inactive product support if we made it part of the security policy [08:41] i.e. that normal users can't access the inactive products at all [08:42] jamesh, I think we just break traversal to them -- isn't that shaking out bugs as well? :) [08:42] The graveyard product you are suggesting would need to be inactive anyway, so the same bugs still need to be shaken out [08:42] stub, it could be left active, so we could do partial undos. [08:42] I am not sure it would need to be inactive, that is my point [08:43] kiko: does that stop me creating branches linked to inactive products? Adding bug tasks to existing bugs against the inactive product? etc [08:43] i should be inactive, because otherwise we are not fulfilling peoples request to delete stuff. We are just shuffling all their stuff to somewhere else still publicly accessible. It would not fulfill the original use case. [08:43] jamesh, ISWYM. [08:43] stub, I think it satisfies a large part of that use case [08:43] (a lot of which is taking up a name slot) [08:44] but IMBW [08:44] just giving out the idea [08:44] of course once someone else creates a branch linked to a product, do we want to let the product owner request its removal? [08:45] if only we attached it to the graveyard :-P [08:45] that isn't really very useful [08:45] I think we change the product name on inactive setting? If not, we should for namespace reasons. [08:45] https://launchpad.net/products/automatix5.8.4 [08:45] we don't AFAIK [08:46] FOOD! [08:48] heh === BenC [n=bcollins@debian/developer/bcollins] has joined #launchpad [08:53] call me forgetful, but how to I merge two teams in lp? [08:53] BenC: you can't and there's a bug open on it [08:54] can I delete a team then? [08:55] bug 29177 [08:55] Malone bug 29177 in launchpad "Allow merging of teams (and specifically merge ubuntu-doc and ubuntu-doc-lists)" [High,Confirmed] http://launchpad.net/bugs/29177 [08:55] no, you can't [08:55] matsubara, how much would break if we just used the person merging code? [08:56] kiko: I don't know, salgado would answer that better than me. He wrote the code together with stub IIRC [08:56] https://launchpad.net/products/julio [08:57] I can't think of anything that would break [08:58] salgado, well, team memberships would need to be handled. === BenC [n=bcollins@debian/developer/bcollins] has left #launchpad ["Ex-Chat"] [08:58] but the workflow would have to ensure the team that is going to be merged into another doesn't have a contact email address [08:59] why not? [08:59] because that's a restriction --we don't merge accounts with email addresses associated [09:00] sounds minor [09:02] yeah, the existing code won't handle team memberships [09:02] that part is specific to people, so it won't work for teams [09:02] need to work out what to do with the losing team's owner [09:02] and make sure you don't form cycles [09:03] e.g. A is a member of B is a member of C [09:03] merging A and C would be an error [09:14] jamesh: ping [09:15] bugrit [09:15] BjornT: ping [09:16] anybody know if I can just give a GeneralFormView an initial_values property ad have it Just Work (TM)? [09:26] sabdfl, yeah, that should work, but the new LaunchpadFormEditView may be a better option [09:27] salgado: i'm looking for a quick fix rather than a refactor [09:28] i'll be SO thrilled if this works! [09:30] bradb: do you want to take a look at https://sodium.ubuntu.com/~andrew/paste/fileSLFc86.html [09:30] oh, wow, it does [09:30] did someone fix generalformview, or did it just work all along? [09:31] bradb: I added the optional selectable checkbox we talked about [09:31] bradb: I also fix a bug, the layout would have been messed up if 'id' wasn't in the show_column === bradb looks [09:33] sabdfl, this was part of some changes I've done to be able to use it on edit forms [09:33] great work, salgado [09:35] bradb: is there a place where i can upload a screenshot, on sodium maybe? [09:36] flacoste: sure, in your public_html dir [09:36] on chinstrap [09:36] great === flacoste uploads screenshot of the form in action [09:39] flacoste: you could make the tal:checkbox into the