[01:32] <mpt> Gooooooooooooooood morning Launchpadders!
[01:34] <kiko-zzz> morning mpt
[01:34] <kiko-zzz> will you do a patch for bugtask-index for me :-)
[02:04] <kiko-zzz> mpt, mpt, mpt
[02:07] <mpt> hmm
[02:07] <mpt> So you want me to reply here instead of USING E-MAIL? :-)
[02:08] <kiko-zzz> no
[02:08] <kiko-zzz> I want you to reply using bzr commit!
[02:08] <mpt> ok
[02:09] <mpt> What do you think of the idea of renaming tags as categories? That could reduce their overuse
[02:10] <kiko-zzz> mpt, interesting idea, but why would it reduce its overuse?
[02:14] <mpt> kiko-zzz, because more people would realize that tags like "biometric", "hide", "hot", "key" etc aren't useful
[02:14] <kiko-zzz> heh, perhaps. but perhaps biometric is useful. :)
[02:14] <kiko-zzz> anyway I'll sleep on it if you send me bzr commits :-)
[02:14] <kiko-zzz> night
[02:14] <mpt> goodnight
[02:15] <mpt> BjornT, have you seen tag clouds?
[02:48] <mpt> lifeless, ping
[02:49] <lifeless> pong
[02:53] <mpt> lifeless, would it have been very difficult to get PQM to accept devpad as well as sodium, rather than instead of?
[02:53] <lifeless> yes
[02:53] <mpt> ok
[02:53] <lifeless> it would have been 'write new code' rather than 'change a config file'
[02:54] <mpt> It's just that the idea of devpad was to *reduce* hostname churn :-)
[02:54] <lifeless> and its now reduced
[02:54] <lifeless> the next relocation will not involve changing the hostname - devpad.canonical.com will stay
[02:55] <mpt> 'Course, now that we've done that, sodium will probably be obstinately permanent ...
[02:57] <lifeless> NMP :)
[03:30] <bluefoxicy> braaaains
[04:36] <mpt> ugh, https://launchpad.net/products/arun.c.k
[04:40] <ajmitch> that looks a bit out of place
[07:50] <BjornT> mpt: no, i don't think i've seen tag clouds. what's that?
[08:05] <mpt> spiv, ping
[08:12] <carlos> morning
[08:15] <mpt> hi carlos
[08:15] <mpt> carlos, have you successfully submitted a merge into devpad yet?
[08:15] <carlos> not yet
[08:15] <carlos> mpt: do you have problems?
[08:16] <mpt> carlos, yes, bzr pqm-submit tries to merge into bazaar-ng.org/bzr/bzr.dev
[08:17] <carlos> what do you have at .bazaar/branches.conf ?
[08:18] <mpt> Exactly as written in <https://launchpad.canonical.com/WorkingWithSharedRepositories>, but with all "sodium.ubuntu.com" changed to "devpad.canonical.com"
[08:20] <carlos> mpt: did you try the --dry-run option ?
[08:20] <carlos> to see what's being send
[08:20] <mpt> yes, that's how I found out it was trying to merge into bazaar-ng.org
[08:21] <carlos> ok, last check
[08:21] <carlos> do you use 'bzr push' to push your branch ?
[08:21] <mpt> yes
[08:21] <carlos> that's the problem then
[08:22] <carlos> edit branches.conf and remove the concrete section for the branch you try to merge
[08:22] <mpt> I shouldn't be using bzr push??
[08:22] <carlos> it's a bug
[08:22] <carlos> mpt: bzr push adds a new section specific for the branch you push
[08:22] <mpt> yes, I noticed that
[08:23] <carlos> then, pqm-submit sees it and doesn't look for the shared repository info
[08:23] <mpt> oh
[08:23] <carlos> just remove it and try again
[08:23] <mpt> hmmm, that's going to suck until the bug is fixed :-)
[08:23] <mpt> ok
[08:23] <mpt> brb
[08:25] <mpt> carlos, that gives me "bzr: ERROR: Not a branch: sftp://devpad.canonical.com/home/warthogs/archives/mpt/launchpad/.bzr/branch/"
[08:26] <carlos> hmmm
[08:27] <carlos> btw, the bug should be fixed soon
[08:27] <carlos> if it's not already fixed
[08:27] <mpt> I tried re-pulling the pqm-submit plug-in, but there were no new revisions
[08:28] <carlos> mpt: did you see that the repository changed ? (I think lifeless said that a couple of weeks ago)
[08:28] <carlos> mpt: from where are you sending the submit request?
[08:29] <mpt> mpt@canonical
[08:30] <mpt> I need to go home now, I'll mail the list about it
[08:30] <mpt> Thanks for your help carlos
[08:30] <carlos> mpt: ok. Btw, I mean the directory ;-)
[08:31] <mpt> I remember there was some discussion about using a /code directory
[08:31] <mpt> but I didn't see any decision about it, and the WorkingWithSharedRepositories page hasn't been updated
[08:31] <carlos> well, I don't think it's the problem
[08:32] <mpt> anyway, tchau
[08:32] <carlos> What I want to know is if you sent the merge request from withing the working tree of your branch
[08:32] <carlos> or from the repository
[08:32] <carlos> he left... ;-)
[09:55] <carlos> later
[10:18] <sivang> morning
[11:05] <danilos> carlos: ping
[11:05] <carlos> danilos: pong
[11:12] <carlos> danilos: ?
[11:15] <ddaa> Good morning
[11:15] <danilos> carlos: sorry, wanted to know what happened with our daily 10am meetings?
[11:15] <danilos> carlos: also wanted to see if we're to do RosettaHighlights one of these days? :)
[11:16] <carlos> danilos: well, I forgot them after the vacations... :-P
[11:16] <carlos> rosettahighlights?
[11:17] <danilos> carlos: you naughty, naughty boy :)
[11:17] <carlos> ddaa: morning
[11:17] <danilos> carlos: like malonehightlights, see the mark's mail on list :)
[11:17] <carlos> danilos: I'm a bit behind with mailing lists...
[11:18] <danilos> ddaa: morning, did sauna feel nice this morning? :)
[11:18] <danilos> carlos: ok, never mind that then :)
[11:18] <ddaa> Ta, Y
[11:18] <ddaa> I'm not in a hotel now
[11:18] <danilos> carlos: I can then do that, and will let you go over it and correct everything :)
[11:19] <ddaa> so I do not have any "fitness center" facility to enjoy close enough to be bothered
[11:19] <danilos> ddaa: you don't have one home? :P
[11:19] <carlos> danilos: go ahead, please
[11:19] <ddaa> danilos: there are probably saunas as large as my whole appartment
[11:22] <danilos> ddaa: :)
[11:31] <carlos> stub: ping
[11:32] <stub> carlos: pong
[11:32] <carlos> stub: about your review
[11:33] <carlos> 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] <carlos> so that script will be removed
[11:34] <carlos> should I change that? 
[11:35] <carlos> or the soyuz copy also needs to shutdown launchpad?
[11:52] <carlos> stub: ?
[11:55] <stub> We can't afford to do this operation without downtime
[11:55] <stub> What calls initializeFromParent?
[11:55] <stub> carlos: ^^^
[11:57] <carlos> stub: a script that is executed to open a new distrorelease
[11:57] <carlos> let me lock for it
[11:58] <carlos> stub: scripts/ftpmaster-tools/initialise-from-parent.py
[12:36] <stub> carlos: Ok. So the verbosity issues apply to that script too - we can't run that script without downtime.
[12:36] <carlos> stub: should I file a bug against soyuz?
[12:37] <stub> And we want to monitor what it is doing.
[12:37] <stub> carlos: If your code just prints to stdout, that should be good enough.
[12:37] <stub> Or uses the standard script logging would be better
[12:37] <stub> (not necessarily the actual SQL - just a notice on what step is being performed.
[12:38] <stub> We can look up the SQL in the source code if we care, or interrogate postgres for that info)
[12:45] <stub> gandwana app servers are going down for some testing
[12:49] <carlos> stub: ok
[12:49] <carlos> thanks
[12:49] <carlos> I will be back in 30 minutes or so
[02:16] <sivang> re
[03:11] <salgado> morning flacoste
[03:11] <flacoste> morning salgado!
[03:12] <salgado> flacoste, I was planning to work on karma for the support tracker.  are you working on something that could conflict with that?
[03:13] <flacoste> salgado: are you using events to assign karma?
[03:15] <salgado> 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] <flacoste> salgado: well, i'm working on the +linkbug, +unlinkbug views, there are also changes to the addview that are pending reviews
[03:18] <salgado> 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] <sivang> morning salgado , flacoste 
[03:30] <flacoste> morning sivang
[03:30] <salgado> hey sivang
[03:34] <sivang> hey salgado , I recerntly looked in our photos from Montreal, I remembered how fun it was on the mountain :-)
[03:35] <salgado> indeed, that was a lot of fun! :)
[03:42] <sivang> salgado: I especially liked the weather :p
[03:42] <salgado> I have to admit that wasn't what I liked the most --too cold for me
[03:45] <sivang> 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] <sivang> It was a real excersize 
[03:48] <ddaa> is pqm known under maintenance ATM?
[03:48] <ddaa> blah
[03:49] <ddaa> ddaa.attention_level = None
[03:49] <ddaa> AttributeError
[03:57] <kiko> mmmmmmmmmmmmm
[03:58] <ddaa> is that the groan of the kiko in the morning?
[03:58] <kiko> I am not feeling super today
[03:58] <dholbach> hellas! can we have a top10 of top contributors on lp.net frontpage? :)
[03:58] <kiko> so watch out!
[03:59] <ddaa> I'm not afraid, I can be more grumpy than you!
[03:59] <salgado> dholbach, we'll have that soon. for now what we have is http://staging.launchpad.net/distros/ubuntu/+topcontributors
[03:59] <dholbach> I'd like to know if there's somebody else between Kamion and me ... karma-wise :)
[03:59] <dholbach> ooooooh *looks*
[04:00] <mdke> s/bacl/back
[04:00] <salgado> hmm. 3 people between you and Kamion
[04:00] <dholbach> the points are not in sync with the lp page, are they?
[04:01] <danilos> kiko: to relax in the morning, you may try re-reviewing bug-44860 branch :P
[04:01] <salgado> they should be one or two days old at most, I think
[04:01] <dholbach> hm ok
[04:01] <kiko> danilos, yeah, today is review day.
[04:01] <kiko> salgado, why are they old?
[04:02] <salgado> 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] <salgado> kiko, because it's staging and I don't know when it was last synced
[04:03] <dholbach> salgado: ok
[04:03] <kiko> oh, staging
[04:03] <kiko> good
[04:03] <kiko> I just thought I had missed a rollout. :)
[04:03] <danilos> kiko: hope you enjoy reviewing it as much as I did writing it :)
[04:07] <kiko> salgado, ping?
[04:07] <salgado> kiko, pong
[04:07] <kiko> salgado, so I note an oddity related to wikis
[04:08] <kiko> https://staging.launchpad.net/people/gnome-l10n-ku
[04:08] <kiko> https://staging.launchpad.net/people/goodgerster
[04:08] <kiko> salgado, the wikinames listed have dupes. any clue why?
[04:09] <salgado> they're for different wikis?
[04:09] <kiko> salgado, ah!
[04:09] <kiko> man that's confusing!
[04:10] <Spads> the wikis could use emblems
[04:14] <sivang> yo kiko 
[04:14] <kiko> Spads, we don't have icons for the wikis though
[04:16] <sivang> hi SteveA 
[04:16] <SteveA> hi sivan
[04:50] <salgado> kiko, will you have time to review that shipit branch this week or maybe I should move it to the general queue?
[04:51] <kiko> salgado, I will have time.
[05:02] <bradb> BjornT: ping
[05:02] <mdke> kiko: did you see my email about the Fridge the other day? any views?
[05:02] <BjornT> hi bradb 
[05:02] <kiko> mdke, I'm happy to post there, though I saw somebody saying that the highlights needed to be heavily edite
[05:02] <kiko> d
[05:03] <bradb> 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] <Ubugtu> Malone bug 6759 in malone "filtering bugs with no upstream filed / blocked on upstream" [Medium,In progress]  http://launchpad.net/bugs/6759
[05:03] <bradb> i noticed a similar problem yesterday
[05:03] <bradb> i think this might be a known problem. ring any bells?
[05:04] <mdke> 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] <kiko> mdke, I do. if so, then great, I'm happy to post there
[05:04] <BjornT> bradb: there's a bug about it, you even reported it yourself once, think :)
[05:04] <bradb> right, anyway, back to my original problem
[05:05] <bradb> BjornT: any reason why the upstream status search UI isn't included on person advanced search?
[05:05] <mdke> 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] <kiko> it was very long
[05:06] <mdke> i think you can exercise your own judgment, I'll make an account for you
[05:07] <stub> kiko, cprov: Do you know offhand which tables we need to sortable on debian version?
[05:07] <kiko> stub, I know sourcepackagerelease, binarypackagerelease, distrorelease at least.
[05:07] <stub> distrorelase??
[05:08] <kiko> stub, amazingly so. look at distrorelease.py
[05:08] <jamesh> you're using debian sorting algorithm for distro versions?
[05:08] <stub> Why on earth would a distrorelease have a debian version number? I suspect it is just a version number
[05:08] <kiko> or hmmm
[05:08] <cprov> stub: in fact, SPP/BPP, which are SQL view, would it be possible ?
[05:09] <stub> cprov: If I create indexes on the underlying tables that should work.
[05:09] <mdke> 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] <cprov> stub: great !
[05:09] <kiko> mdke, okay,will join now
[05:10] <kiko> mdke, applied.
[05:11] <kiko> mdke, ubuntu-fridge needs an emblem!!11!
[05:11] <mdke> how safe is it to send passwords over launchpad team approval email?
[05:11] <kiko> stub, I could swear we compared distrorelease versions using apt_pkg, but..
[05:11] <kiko> mdke, passwords?
[05:12] <BjornT> 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] <kiko> aha!
[05:12] <mdke> I suppose it depends on the sensitivity of the password huh
[05:12] <kiko> stub, see distribution.py -- it uses sourcerer.deb.version to sort releases.
[05:13] <stub> Ok. No point creating an index though since we only have a handful of distroreleases
[05:13] <kiko> stub, AGREED. :)
[05:13] <bradb> BjornT: and yet it shows on the upstream bug search page! ;)
[05:13] <bradb> i'll fix those issue while i'm in the neighbourhood today
[05:13] <kiko> bradb, the dude!
[05:15] <LarstiQ> bradb: The Black Lotus?
[05:15] <bradb> The Big Lebowski!
[05:15] <LarstiQ> doh!
[05:15] <LarstiQ> there goes my irc-as-a-stack reading habit again
[05:16] <sivang> bradb: oh man, that movie is SO rad
[05:16] <sivang> bradb: I've watched it a dozen of times at least
[05:17] <BjornT> bradb: well, it does make sense on the *product* bug search page. for example zope and sqlobject are upstream to launchpad.
[05:18] <bradb> 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] <bradb> feel free to explain why I'm wrong though
[05:19] <bradb> i'd be even more blown away if it turns out the current search would actually /work/ for that case right now!
[05:19] <kiko> bradb, it should probably work, but then the word "Upstream" doesn't :) it would be "other products"
[05:20] <dholbach> LarstiQ: the black lotus! and the Mox Pearl!
[05:20] <LarstiQ> dholbach: I was thinking of the demo group though :)
[05:20] <dholbach> LarstiQ: who cares of the demo group if you have 5 moxes and a black lotus! :-p
[05:20] <bradb> 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] <BjornT> 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] <kiko> bradb, no, no.
[05:21] <LarstiQ> dholbach: they don't run on my amiga!
[05:21] <kiko> BjornT, right. we can't currently do that.
[05:21] <LarstiQ> dholbach: http://pouet.net/prod.php?which=25778 for instance
[05:21] <bradb> BjornT: that's what i'm saying
[05:21] <kiko> BjornT, well, we can, but the word "upstream" won't work.
[05:21] <kiko> the reason I say that
[05:21] <kiko> is that say you have a bug with ubuntu and debian tasks
[05:22] <kiko> you can go to ubuntu
[05:22] <kiko> and query for "upstream" tasks
[05:22] <kiko> and it would return debian
[05:22] <kiko> you can also go to debian
[05:22] <kiko> and query for 'upstream' tasks
[05:22] <kiko> and it would return ubuntu
[05:22] <kiko> now ubuntu is not upstream to debian
[05:22] <kiko> but we have no way of telling the situations apart in our data model
[05:22] <BjornT> yeah, i know, that's why i labeled it 'status elsewhere' at first
[05:22] <kiko> upstream to us means products
[05:22] <kiko> right.
[05:22] <LarstiQ> kiko: on a per package basis it might be?
[05:23] <kiko> LarstiQ?
[05:23] <dholbach> LarstiQ: http://en.wikipedia.org/wiki/Power_Nine#Black_Lotus - but i now better shut up before i get smacked
[05:24] <bradb> kiko: OTOH, we do use a "(upstream)" suffix for affected products
[05:24] <kiko> bradb, not OTOH -- it's the same hand. upstream for us is products!
[05:24] <LarstiQ> kiko: for a particular package, debian can be getting it from ubuntu rather than the other way around
[05:24] <stub> 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] <kiko> bradb, I was making a case for not saying "upstream" when we mean the relative association between OSS things.
[05:24] <bradb> yeah, i know
[05:25] <bradb> what i'm getting at is that, currently, both product and upstream are confusing words for the search ui
[05:25] <kiko> stub, you're amazing! thanks!
[05:25] <kiko> woo this will be excellent
[05:25] <kiko> really help memory usage and perf for searches
[05:25] <cprov> stub: comment, the bug in question, I will try some tests ASAP. Thanks you, dude !
[05:26] <bradb> 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] <bradb> 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] <BjornT> 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] <bradb> 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] <bradb> we may learn that it's wrong, and then it's easy to change
[05:29] <SteveA> what's this padlock symbol against email addresses?
[05:30] <bradb> 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] <SteveA> I'm told it means "private email address"
[05:30] <bradb> kiko, BjornT: thoughts?
[05:30] <SteveA> but I don't see how a padlock indicates privacy
[05:31] <salgado> the padlock is also what we use to indicate privacy for bugs
[05:32] <kiko> bradb, either upstream == product or use the text "elsewhere" and search through any other context's bugtasks.
[05:32] <salgado> (I'm not arguing I think it indicates privacy, though)
[05:32] <BjornT> bradb, kiko: personally i'd go for 'status elsewhere'.
[05:32] <kiko> SteveA, that padlock was added as part of your request, fwiw
[05:32] <SteveA> did I specify a *padlock* >?
[05:32] <kiko> SteveA, only admins and the user himself can see that
[05:32] <SteveA> I must have been on crack
[05:32] <kiko> SteveA, no, you didn't, and if you have a better icon, provide me with one, otherwise, booo :-)
[05:34] <ddaa> I think a padlock is a good way to evocate secrecy.
[05:35] <kiko> thank you ddaa 
[05:35] <ddaa> Everybody is familiar with that from https
[05:35] <LarstiQ> not everyone understands even https
[05:35] <kiko> SteveA, by the way, you reviewed that patch. it is r=SteveA. :-P
[05:36] <bradb> 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] <bradb> s/I'll/I'm/
[05:36] <SteveA> kiko: I'll take a photo of the "do not disturb" sign you can put on your door at the hotel
[05:37] <BjornT> 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] <kiko> BjornT, that won't work, distro bugs can be part of a number of upstreams.
[05:38] <kiko> bradb, okay, if you think the feature won't work for other contexts as easily, I'm fine with upstream or product.
[05:38] <BjornT> kiko: well, i was thinking of having something to say 'any other product or distribution' as well.
[05:38] <sabdfl> stub: mail sent
[05:39] <SteveA> kiko: this one will do: http://images.google.com/images?q=+privacy+holtzspa
[05:39] <kiko> BjornT, we can do that, but I don't think it needs to be done now
[05:39] <kiko> BjornT, otherwise we're stretching bradb's branch
[05:39] <bradb> 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] <bradb> indeed. i'd prefer to do as little as possible
[05:40] <stub> sabdfl: So according to your email, you can't merge rocketfuel into that branch?
[05:40] <kiko> SteveA, sabdfl: do I need to reply to gward's latest email?
[05:40] <SteveA> kiko: did you just forward it?
[05:40] <BjornT> bradb: fixes available in debian is a use case as well.
[05:40] <sabdfl> 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] <stub> It is already in rocketfuel
[05:41] <sabdfl> can you please not do that again?
[05:41] <stub> Sure. I just don't understand what the problem is.
[05:41] <sabdfl> say i wanted to tweak column names
[05:41] <kiko> SteveA, no, it went to the launchpad list
[05:41] <sabdfl> i would have to merge two unrelated files in bzr
[05:41] <SteveA> kiko: how long ago?
[05:41] <sabdfl> we have an expensive rcs just for this
[05:41] <bradb> BjornT: I think the strongest use case is just "Fix available"
[05:42] <kiko> SteveA, a few hours
[05:42] <SteveA> kiko: I seem to be missing it
[05:42] <stub> sabdfl: patch is here: https://sodium.ubuntu.com/~andrew/paste/fileuwGw9q.html
[05:42] <BjornT> bradb: agreed, just as long as debian bugs are included there.
[05:42] <sabdfl> stub: that's rather not the point
[05:42] <stub> sabdfl: If you want to tweak column names, then it would need a new review anyway.
[05:42] <kiko> sent.
[05:43] <stub> sabdfl: Which would indicate you asked for a review too early.
[05:43] <sabdfl> stub: nonetheless, please do not commit alternate version of the same file
[05:43] <kiko> 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] <sabdfl> kiko: he never merged my branch
[05:43] <kiko> oh was the file renamed?
[05:43] <sabdfl> he just committed a new file
[05:43] <stub> I didn't merge marks branch, so one revision would need to be removed.
[05:43] <kiko> ah I see
[05:43] <sabdfl> with a different name
[05:43] <kiko> ah right.
[05:43] <kiko> yeah that kinda fucks up the rcs
[05:43] <sabdfl> and no history
[05:43] <sabdfl> in fact, stub please delete that file
[05:44] <kiko> is it in RF already?
[05:44] <sabdfl> i have a series of changes committed, and each of them is tied to having the right version of that file
[05:44] <kiko> if so just merge RF and copy the file over and delete it
[05:44] <SteveA> kiko: I'll reply to you with my comments
[05:44] <sabdfl> kiko: no
[05:44] <sabdfl> stub, please fix this
[05:44] <kiko> then your old file history is preserved and you nuke out the new file
[05:44] <kiko> SteveA, oookay
[05:46] <flacoste> 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] <bradb> flacoste: which macro?
[05:46] <flacoste> bradb: 'table'
[05:47] <flacoste> bradb: only advanced_search_form seems to be used, the other ones 'btached-table', 'item' are defined but not used
[05:47] <flacoste> bradb: at least according to grep '+bugtask-macros-tableview' templates/*
[05:48] <SteveA> kiko: he seems happy that you were responsive to his queries
[05:48] <kiko> SteveA, yeah. he didn't ask me anything this time around though
[05:49] <bradb> 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] <bradb> with batching, etc
[05:49] <flacoste> bradb: because I need the 'select' column
[05:50] <flacoste> bradb: i.e. add a checkbox to each row
[05:50] <bradb> yeah
[05:50] <flacoste> brabd: which the other listing in use doesn't have
[05:51] <bradb> 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] <bradb> because we have a use for a checkbox in Malone too
[05:52] <bradb> what do you think?
[05:53] <flacoste> bradb: I agree that it's better to reuse what is used elsewhere
[05:53] <flacoste> 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] <bradb> bugs-listing-table.pt is the meat of it, and includes a way of showing/hiding columns on demand
[05:54] <bradb> e.g. <th tal:condition="context/show_column/packagename|nothing">
[05:54] <flacoste> bradb: yep, I've look at that file
[05:55] <flacoste> bradb: what do you think if I put an empty slot at the beginning of each data row?
[05:56] <bradb> flacoste: i'd say show a column with a checkbox, if needed, otherwise don't show that column
[05:56] <bradb> an empty slot adds no value to the UI
[05:57] <bradb> if you're feeling frisky, you could even refactor it to "context/shouldShowPackageName"
[05:57] <flacoste> 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] <flacoste> bradb: i'll pass the context/shouldShowPackageName refactoring for now, there is already enough stuff on my branch :-)
[05:59] <bradb> 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] <flacoste> 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] <bradb> 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] <bradb> that is, i /can/ think of various generic uses, of course
[06:02] <flacoste> bradb: ok, i'm overengineering, in /my/ case, I can live with the selected_bug_id name, so I'll do that
[06:02] <kiko> carlos, do you know when we will move the translation focus to edgy?
[06:02] <bradb> flacoste: cool
[06:02] <flacoste> bradb: when that name won't work, we'll refactor then
[06:03] <bradb> good call
[06:03] <kiko> danilos[out]  ^^^
[06:03] <flacoste> bradb: should I put a header on that checkbox column or just extend the Summary colspan?
[06:05] <bradb> flacoste: you could just render a cb to the left of the bug icon. no extra td even needed.
[06:06] <flacoste> bradb: fine
[06:06] <flacoste> bradb: other question: what about the checkbox label: should I wrap the title in a label tag?
[06:07] <bradb> hm, good question
[06:07] <flacoste> bradb: the label is neat for testbrowser: browser.getControl('Firefox crashes').selected = True
[06:09] <bradb> i'm just pondering which of, say, the bug icon, bug id, and title should be labels
[06:09] <bradb> maybe none, maybe all
[06:10] <flacoste> all would be problematic: they are in different td
[06:10] <carlos> kiko: I got the approval from stuart to merge my changes to open Edgy
[06:10] <bradb> you'd have to use for id notation
[06:10] <carlos> as soon as we execute the script to open Edgy, we can change it
[06:11] <flacoste> bradb: no i mean, the id, icon and title are all in different tds, i can wrap them in one label element
[06:11] <kiko> 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] <flacoste> s/can/can't/
[06:11] <carlos> kiko: the migration from breezy to dapper and the migration from dapper to edgy
[06:11] <bradb> flacoste: yeah, i know, that's why i'm saying you'd have to use the for="id" notation
[06:11] <carlos> kiko: so we reuse translations only in Rosetta
[06:11] <bradb> <label for="id">blah</label>
[06:12] <carlos> kiko: that was our main task in London last sprint
[06:12] <kiko> carlos, did we never migrate from breezy to dapper?
[06:12] <carlos> no
[06:12] <kiko> oh
[06:12] <flacoste> bradb: but td can't nest in label
[06:12] <kiko> hmmm
[06:12] <kiko> I would have appreciated email on it. is there a spec?
[06:12] <flacoste> bradb: and is there another way then the for attribute to link a label to its control?
[06:13] <bradb> flacoste: <td><label for="id">blah</label></td><td><label for="id">something else</label></td>
[06:13] <flacoste> bradb: you sure that would work?
[06:13] <carlos> kiko: I had a preimplementation call with spiv about it
[06:13] <carlos> kiko: in fact, you complained about the solution
[06:13] <carlos> kiko: so you read it ;-)
[06:13] <flacoste> bradb: with testbrowser I mean, i'm not sure you can have more than one label by control
[06:13] <kiko> yeah I remember
[06:13] <bradb> 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] <kiko> but I only read it highlevel and didn't know what the real problem was
[06:14] <kiko> carlos, so no spec or email? that's really bad
[06:14] <bradb> flacoste: but i would surprised if multiple labels for the same id didn't work
[06:14] <BjornT> 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] <carlos> 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] <carlos> I guess a concrete spec would be better
[06:15] <kiko> or even email
[06:15] <kiko> explaining the problem
[06:15] <bradb> 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] <kiko> I mean I don't expect heavyweight anything for everything
[06:16] <kiko> but I hope people bring up the issues via email as they appear
[06:16] <bradb> 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] <BjornT> 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] <bradb> BjornT: flacoste suggested it for testing
[06:18] <bradb> i.e. with testbrowser
[06:18] <flacoste> BjornT: browser.getControl('Firefox crashes').selected = True
[06:19] <bradb> flacoste: or even, browser.getControl(firefox_crashes.title).selected = True
[06:19] <bradb> but either are probably god
[06:19] <bradb> and good
[06:19] <BjornT> 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] <flacoste> BjornT: well, it's just that I think that 'Firefox crashes' is more meaningful than browser.getControl('1').selected = True
[06:21] <flacoste> but I won't fight untill death over that
[06:22] <flacoste> BjornT: and I agree, that since the title is already a link, it has less value as a label
[06:22] <flacoste> so I think the bug id and icon could be labels
[06:23] <flacoste> that means that konq shouldn't support either...
[06:38] <ddaa> :)
[06:38] <kiko> good man.
[06:43] <kiko> BjornT, how much work to make tags work across a project?
[06:48] <BjornT> kiko: what do you mean?
[06:50] <kiko> BjornT, well, to be able to search for field.tag on /projects/launchpad/+bugs
[06:51] <kiko> oh
[06:51] <kiko> it already works!
[06:51] <kiko> BjornT, rock on!
[06:51] <BjornT> :)
[06:52] <sabdfl> BjornT: major, major brownie points there, i think
[06:53] <kiko> heh
[07:18] <carlos> stub: hi, around?
[07:18] <stub> carlos: yes
[07:19] <carlos> 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] <carlos> that is loking the database
[07:19] <carlos> s/loking/locking/
[07:20] <carlos> stub: but I don't see anything on mawson that looks like a connection to asuka
[07:21] <stub> carlos: fixed
[07:21] <carlos> stub: thanks
[07:23] <carlos> staging is back ;-)
[07:45] <steveire> Has anyone had shipit cds sent to germany and how long might it take?
[07:47] <steveire> Also, is it possible that I can change the destination for the cds if they don't arrive before I leave?
[07:48] <kiko> steveire, have they already been shipped?
[07:48] <salgado> steveire, they usually take around 6 weeks to deliver.  might be faster to germany, though
[07:48] <steveire> Can I tell from the launchpad site if they have or not?
[07:49] <steveire> 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] <salgado> steveire, then it's probably shipped already, and it's not possible to change the shipping address
[07:50] <salgado> steveire, on https://shipit.ubuntu.com you should be able to see the date it was sent to the shipping company
[07:51] <steveire> 10 CDs requested in 2006-07-25. 10 CDs approved and sent to the shipping company in 2006-07-25
[07:51] <steveire> where do they get shipped from? Is there one source or several?
[07:52] <salgado> Netherlands, IIRC
[07:54] <steveire> alright, cool. I'll see what happens. Thanks for the info.
[07:55] <salgado> np
[08:05] <SteveA> kalosaurusrex: hi
[08:08] <kiko> SteveA, do you approve my codeofconduct tag?
[08:09] <SteveA> kiko: the meeting is tomorrow.  i haven't looked.
[08:09] <kiko> oh, they are only approved at meetings? I did not know.
[08:09] <SteveA> is it urgent?
[08:09] <kiko> nope.
[08:09] <kiko> I'm already using it :)
[08:09] <SteveA> i'm about to get together with gustavo and write up the widget refactoring to take over the world
[08:09] <kiko> whoa!
[08:09] <kiko> that's great to hear
[08:09] <SteveA> it is rad
[08:10] <kiko> make it kick butt
[08:17] <kiko> stub, ping
[08:17] <stub> kiko: pong
[08:17] <kiko> stub, https://launchpad.net/products/malone/+bug/29227
[08:17] <Ubugtu> Malone bug 29227 in malone "Searching for "pmu" doesn't find "/dev/pmu"" [High,In progress]  
[08:17] <kiko> stub, fixed released, right?
[08:18] <stub> No
[08:18] <kiko> it works now
[08:18] <kiko> stub?
[08:18] <stub> How odd. Please leave it open - I expect it is working by accident
[08:18] <kiko> ok.
[08:20] <flacoste> SteveA: are you extending the base zope3 widget or will it be a completely different framework?
[08:20] <SteveA> it will be much much simpler
[08:20] <SteveA> but *may* be compatible with zope widgets via a wrapper
[08:20] <SteveA> we'll see about that
[08:21] <flacoste> 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] <jamesh> kiko: I've got some updates to the LaunchpadFormView class to let us address the tabindex problem
[08:23] <jamesh> kiko: there is also support for overriding a particular widget's error from the form-wide validation method
[08:24] <kiko> jamesh, I saw your bug comment -- very neat!
[08:24] <kiko> carlos, https://launchpad.net/products/rosetta/+bug/2022 -- ?
[08:24] <Ubugtu> Malone bug 2022 in rosetta "iso-codes is not available for breezy" [High,Confirmed]  
[08:32] <kiko> salgado, stub: I just had an ingenious idea: instead of nuking products, /merging/ products!
[08:32] <kiko> 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] <stub> What use cases are you trying to solve?
[08:33] <kiko> stub, product deletion and product 'migration'
[08:33] <kiko> we could delete products by merging them with a graveyard product
[08:33] <stub> I don't see how it helps product deletion. Migration and merging incorrectly displayed products, yes.
[08:34] <kiko> and we could then make the graveyard product be admins-accessible only or whatever
[08:34] <kiko> well, there's the idea anyway. 
[08:34] <stub> Why have a graveyard product? Why not just flag the product as inactive?
[08:34] <kiko> stub, well, mostly because it makes any link to the product (which can come from many places) break.
[08:35] <kiko> whereas with a merged product those links would be updated
[08:35] <stub> Why would that not be the case for a graveyard product too?
[08:35] <salgado> we'd need to special case the graveyard product everywhere, no?
[08:35] <kiko> stub, the product would still be around, but it would be one product instead of 100 products being deleted.
[08:35] <salgado> isn't that the same as special casing inactive products?
[08:35] <kiko> salgado, we could if we wanted to, but it wouldn't be necessary.
[08:35] <kiko> we could still allow traversal to it
[08:36] <kiko> I mean "wouldn't ne /necessary/"
[08:36] <kiko> as part of the solution
[08:36] <stub> 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] <stub> In particular, if we merge to a graveyard product we have no way of undoing the operation.
[08:36] <kiko> the only thing you lose is the name of the original product..
[08:37] <kiko> that is true.
[08:37] <stub> I'm not sure if it would screw up the supermirror either.
[08:37] <kiko> but I hate to see the dozens of bogus products registered
[08:37] <kiko> and not be able to do it 
[08:37] <stub> (but merging would be good for other use cases)
[08:37] <kiko> do anything
[08:37] <stub> So flag them as inactive.
[08:38] <kiko> hmmm.
[08:38] <kiko> maybe I should try and tell you how that worked out. :)
[08:39] <kiko> freeCD
[08:39] <kiko> ubuntu
[08:39] <kiko> Registered by  arun.c.k on 2006-08-08
[08:39] <kiko> stub, one thing I'm concerned about flagging it as inactive is that I don't know how much will break 
[08:39] <jamesh> stub/kiko: merging products could lead to branch name collisions
[08:39] <kiko> whereas with merging I know -- nothing will.
[08:40] <stub> ha!
[08:40] <kiko> jamesh, well, the branches would need to be renamed, yes. 
[08:40] <stub> So you want to add new features to avoid finding possible bugs in existing features?
[08:40] <kiko> stub, I think the active/inactive feature is just a lot harder to get right.
[08:41] <kiko> a product now has a series related to it to.. ugh
[08:41] <jamesh> kiko: we'd shake bugs out of inactive product support if we made it part of the security policy
[08:41] <jamesh> i.e. that normal users can't access the inactive products at all
[08:42] <kiko> jamesh, I think we just break traversal to them -- isn't that shaking out bugs as well? :)
[08:42] <stub> The graveyard product you are suggesting would need to be inactive anyway, so the same bugs still need to be shaken out
[08:42] <kiko> stub, it could be left active, so we could do partial undos.
[08:42] <kiko> I am not sure it would need to be inactive, that is my point
[08:43] <jamesh> kiko: does that stop me creating branches linked to inactive products?  Adding bug tasks to existing bugs against the inactive product? etc
[08:43] <stub> 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] <kiko> jamesh, ISWYM.
[08:43] <kiko> stub, I think it satisfies a large part of that use case
[08:43] <kiko> (a lot of which is taking up a name slot)
[08:44] <kiko> but IMBW
[08:44] <kiko> just giving out the idea
[08:44] <jamesh> 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] <kiko> if only we attached it to the graveyard :-P
[08:45] <jamesh> that isn't really very useful
[08:45] <stub> I think we change the product name on inactive setting? If not, we should for namespace reasons.
[08:45] <kiko> https://launchpad.net/products/automatix5.8.4
[08:45] <kiko> we don't AFAIK
[08:46] <stub> FOOD!
[08:48] <kiko> heh
[08:53] <BenC> call me forgetful, but how to I merge two teams in lp?
[08:53] <matsubara> BenC: you can't and there's a bug open on it
[08:54] <BenC> can I delete a team then?
[08:55] <matsubara> bug 29177
[08:55] <Ubugtu> 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] <matsubara> no, you can't
[08:55] <kiko> matsubara, how much would break if we just used the person merging code?
[08:56] <matsubara> kiko: I don't know, salgado would answer that better than me. He wrote the code together with stub IIRC
[08:56] <kiko> https://launchpad.net/products/julio
[08:57] <salgado> I can't think of anything that would break
[08:58] <kiko> salgado, well, team memberships would need to be handled.
[08:58] <salgado> 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] <kiko> why not?
[08:59] <salgado> because that's a restriction --we don't merge accounts with email addresses associated
[09:00] <kiko> sounds minor
[09:02] <salgado> yeah, the existing code won't handle team memberships
[09:02] <salgado> that part is specific to people, so it won't work for teams
[09:02] <jamesh> need to work out what to do with the losing team's owner
[09:02] <jamesh> and make sure you don't form cycles
[09:03] <jamesh> e.g. A is a member of B is a member of C
[09:03] <jamesh> merging A and C would be an error
[09:14] <sabdfl> jamesh: ping
[09:15] <sabdfl> bugrit
[09:15] <sabdfl> BjornT: ping
[09:16] <sabdfl> anybody know if I can just give a GeneralFormView an initial_values property ad have it Just Work (TM)?
[09:26] <salgado> sabdfl, yeah, that should work, but the new LaunchpadFormEditView may be a better option
[09:27] <sabdfl> salgado: i'm looking for a quick fix rather than a refactor
[09:28] <sabdfl> i'll be SO thrilled if this works!
[09:30] <flacoste> bradb: do you want to take a look at https://sodium.ubuntu.com/~andrew/paste/fileSLFc86.html
[09:30] <sabdfl> oh, wow, it does
[09:30] <sabdfl> did someone fix generalformview, or did it just work all along?
[09:31] <flacoste> bradb: I added the optional selectable checkbox we talked about
[09:31] <flacoste> bradb: I also fix a bug, the layout would have been messed up if 'id' wasn't in the show_column
[09:33] <salgado> sabdfl, this was part of some changes I've done to be able to use it on edit forms
[09:33] <sabdfl> great work, salgado
[09:35] <flacoste> bradb: is there a place where i can upload a screenshot, on sodium maybe?
[09:36] <bradb> flacoste: sure, in your public_html dir
[09:36] <bradb> on chinstrap
[09:36] <flacoste> great
[09:39] <bradb> flacoste: you could make the tal:checkbox into the <label> instead
[09:40] <bradb> that would remove a bit of zcml
[09:40] <flacoste> you mean put the input and icon in the label?
[09:41] <flacoste> bradb: take a look at https://chinstrap.canonical.com/~flacoste/linkbugs.png
[09:41] <bradb> flacoste: yeah, input and icon inside the label tag.
[09:42] <bradb> i think the ui looks good
[09:42] <bradb> what's with the 1 - 7 of 13, btw? it should show all 13.
[09:42] <bradb> maybe you were just testing batching
[09:43] <flacoste> bradb: i am
[09:43] <sladen> in "+bug", where did the link to "Link to external bugtracker" go?
[09:43] <bradb> flacoste: ah, ok
[09:43] <flacoste> bradb: i'm using the default config.malone.batch_size which should be lower when running locally
[09:44] <bradb> sladen: you can use the "Also affects:" + Upstream... link under the table
[09:44] <flacoste> bradb: don't you find it confusing that the same bug appears many times?
[09:45] <sladen> bradb: cool, ta thanks
[09:46] <bradb> flacoste: yeah, it's confusing, and it's a known problem. it's not the quickest thing to fix right now, unfortunately.
[09:48] <flacoste> bradb: in the new diff, i forgot to add the tal: namespace on the label condition
[09:51] <bradb> flacoste: you can remove tal:id_column, and put the condition in the td
[09:51] <bradb> unless you always want that td?
[09:52] <flacoste> bradb: that was the bug I fixed, summary has a fixed colspan of 3, if that td doesn't appear the layout will be messed up
[09:52] <bradb> i thought that might be it
[09:53] <flacoste> bradb: should I merge that patch in rocketfuel r=bradb or should I merge it later with the rest of my branch?
[09:54] <bradb> the only other than that concerns me is the indentation
[09:54] <bradb> it breaks my mental parser
[09:54] <bradb> how bad does it look with neat indentation?
[09:57] <kiko> make: *** [check]  Error 1
[09:57] <kiko> bradb,  ^^^
[09:58] <bradb> kiko: ?
[09:58] <bradb> context?
[09:58] <kiko> weren't you merging something into PQM?
[09:58] <bradb> that landed
[09:58] <kiko> m
[09:58] <kiko> wonder who it was that got the boot then
[09:59] <flacoste> bradb: https://chinstrap.canonical.com/~flacoste/linkbugs-2.png
[09:59] <flacoste> bradb: the way to see the difference is by going back-forward between the two
[10:00] <kiko> flacoste, what does that form do?
[10:00] <bradb> flacoste: yeah, hm
[10:01] <flacoste> kiko: it closes bug 52781
[10:01] <Ubugtu> Malone bug 52781 in launchpad-support-tracker "Link bug should allow searching" [Wishlist,In progress]  http://launchpad.net/bugs/52781
[10:01] <kiko> flacoste, is it for linking a ticket to a bug?
[10:02] <kiko> if it is, I think that UI is way way overkill for the task
[10:02] <flacoste> kiko: cve, ticket, support, you name it (actually an IBugLinkTarget)
[10:02] <flacoste> s/support/specification/
[10:02] <kiko> hmmm
[10:02] <flacoste> kiko: you can still enter a bug id
[10:03] <kiko> and then click on a checkbox and then on a button?
[10:03] <flacoste> kiko: you'll get a confirmation that you had the right id before the linking happen
[10:03] <kiko> I don't like that very much tbh
[10:03] <flacoste> kiko: you don't?
[10:03] <kiko> because it makes the most important use case, which is linking to an ID you already know, much slower.
[10:03] <kiko> if you are going to report a bug it will be work anyway
[10:04] <flacoste> kiko: well, everytime i've used that feature, I always had to use the bugs search page to find the number
[10:04] <sabdfl> sivang: whats the status on your Braindum -> New branch?
[10:04] <kiko> flacoste, that's fine -- that's what the bug search page is for. :)
[10:04] <kiko> sabdfl, it's pending review from me I think?
[10:04] <sabdfl> ok, i was going to merge it into mine, and put the whole lot up for review
[10:05] <kiko> flacoste, offering a link to the bug search page is fine
[10:05] <flacoste> kiko: yeah, but I find it a lot more convenient if I don't have to open a new tab, search, copy and paste the id and hope that I copy the id correctly :-)
[10:05] <kiko> of course
[10:05] <flacoste> kiko: other advantage is that you can link multiple bugs at once
[10:05] <kiko> flacoste, it's still overkill for the task you have though -- and most users will be confused by it.
[10:06] <kiko> except you don't normally link multiple bugs at once to things
[10:06] <kiko> so the UI seems to promote linking multiple bugs at once
[10:06] <kiko> whereas the most common case is linking a single bug
[10:07] <kiko> maybe. I think for CVEs, though, people end up linking the CVEs from the bug themselves.
[10:07] <sivang> sabdfl: waiting review over kiko's
[10:08] <kiko> flacoste, so I see pretty weak justification for a link-to-multiple-bugs UI in general
[10:08] <flacoste> kiko: our data model allows it
[10:08] <kiko> flacoste, note that I see strong justification for mass-change bug UI 
[10:09] <kiko> flacoste, note that I said UI, not schema. :)
[10:09] <flacoste> well, the UI should enable to make the most use of our schema
[10:09] <flacoste> otherwise, it's just over-engineering
[10:09] <flacoste> s/enable/enables us/
[10:10] <kiko> flacoste, only if there's a good, important use case for the UI. otherwise it's just a feature that we need to maintain and that nobody will use.
[10:10] <kiko> (and we have more of those than I like)
[10:11] <flacoste> for wimw, i personnally would use more the link bugs feature if it was easier to use. i find the current 'enter id' very inconvenient, that's why I filled the bug
[10:11] <kiko> I hadn't noticed you had filed the bug
[10:11] <kiko> I still think this feature is overkill and that there are much more valuable fish to fry...
[10:11] <flacoste> but maybe that's what you don't want ;-)
[10:12] <sivang> sabdfl: is this the stars for essential people on specs branch ?
[10:12] <kiko> well, if you think it's got merit, try convincing mpt of it. I'd be happy to see his opinion on it
[10:13] <flacoste> kiko: i'll send an email to MPT with the screen shots
[10:13] <kiko> ok.
[10:13] <kiko> flacoste, one thing that really disturbs me in that page is that there is no indication of what I'm doing -- linking what to what?
[10:13] <kiko> I'll be quiet now
[10:14] <flacoste> kiko: and put that branch away for the moment (it already contains a fix for bug 49760 - for CVE and Ticket)
[10:14] <Ubugtu> Malone bug 49760 in launchpad-support-tracker "UI improvements to remove bug link page: change label, use selection" [Medium,In progress]  http://launchpad.net/bugs/49760
[10:15] <flacoste> kiko: the screenshot you see was only to show to bradb the result of the checkbox patch to bradb, i haven't merged the text from the existing templates yet
[10:16] <flacoste> kiko: what fish do you want to fry while I wait for mpt's feedback?
[10:17] <sabdfl> sivang: and one or two other little fixes
[10:17] <kiko> okay
[10:17] <kiko> ah! fish!
[10:19] <kiko> flacoste, well, brainstorming, an incoming email interface for the ticket tracker would be cool.
[10:19] <kiko> :)
[10:20] <kiko> flacoste, a way to forward tickets, or even easily assign tickets to somebody, would be nice as well
[10:20] <flacoste> kiko: well, that smells like a post-1.0 feature 
[10:20] <kiko> flacoste, in-page editing of the ticket?
[10:20] <sivang> mmm, Dennis in butter
[10:20] <flacoste> kiko: what's in-page editing?
[10:20] <sabdfl> grrrrrr
[10:20] <kiko> :)
[10:20] <kiko> something that makes editing the ticket convenient.
[10:20] <sabdfl> let's do simple, then AJAX, hmk?
[10:21] <sabdfl> in-between steps only where it's crucial, like bugtask
[10:23] <kiko> well
[10:23] <kiko> it just makes the ticket tracker less usable. instead of setting assignees people just comment in the bug
[10:23] <kiko> err in the ticket. freudian freudian
[10:24] <kiko> that's certainly more valuable than linking to multiple bugs at any rate.
[10:24] <kiko> flacoste, renaming Support to Answer everywhere is another high-benefit change
[10:25] <flacoste> kiko: ok, renaming 'Support' to 'Answer', that is something that needs to be done for 1.0, so I'll get on this
[10:27] <kiko> salgado, https://launchpad.net/products/launchpad/+ticket/753
[10:27] <kiko> salgado, https://launchpad.net/products/launchpad/+ticket/817
[10:27] <kiko> salgado, I think this hasn't been happening anymore -- right?
[10:28] <kiko> flacoste, what about a view so I can see support requests assigned to me?
[10:28] <flacoste> kiko: otherwise, at the sprint, we aggreed to focus on the community features for 1.0 and leave the features using the more 'commercial support' oriented attributes of our data model for post 1.0 (that is assignee, priority, datedue, etc.)
[10:28] <kiko> agreed
[10:29] <flacoste> the view to be implemented for 1.0 are defined in the support-tracker-views spec
[10:29] <flacoste> s/view/views/
[10:29] <flacoste> but I wanted to finish support-tracker-workflow before updating the views
[10:30] <kiko> ok.
[10:30] <salgado> kiko, I haven't seen any of them lately
[10:30] <kiko> me neither
[10:31] <flacoste> kiko: about the renaming: every occurance of support should be replaced by answer?
[10:31] <kiko> flacoste, well... it's not a simple sed, no :)
[10:31] <flacoste> like facet, the link at the bottom of the page
[10:31] <kiko> salgado, this guy: https://launchpad.net/people/simosx/ keeps getting duplicate accounts created 
[10:31] <kiko> he has merged his account twice now :)
[10:32] <flacoste> kiko: i know it's not a sed :-) i just want to know how deep you want that renaming to go
[10:32] <salgado> kiko, aparently he gets them because of translations he made?
[10:32] <flacoste> kiko: only user visiable strings or also refs in the code?
[10:32] <kiko> flacoste, the user-visible bits should probably be called "Answers". I just don't know how well that will fit into every sentence, but yes, that's the idea.
[10:32] <kiko> flacoste, I don't think renaming the code is worth it.. the code refers to tickets IIRC. :)
[10:33] <kiko> salgado, yeah, imported translations probably.
[10:33] <flacoste> kiko: so a 'Support request' become an 'Answer request'?
[10:33] <kiko> got a funny ring to it
[10:37] <flacoste> well, it sounds imperative: I want an 'Answer now!'
[10:38] <sivang> flacoste: when you are done with kiko, I'd be interested in some possible hand holding for fixing that LP wide Choice() validation issue, using the standard zope form way,  as you explained previously.
[10:38] <kiko> I think "answer tracker" is cool.
[10:38] <kiko> I don't know whether the individual items should be called "answer requests". maybe "tickets" is fine after all
[10:39] <flacoste> sabdfl: what do you think about 'Answer request' vs 'ticket'?
[10:39] <sivang> flacoste: I'd possibly need hand holding for the first steps, and continue on my own.
[10:39] <flacoste> sivang: i'm not sure, but there might be a new way to fix this
[10:40] <flacoste> sivang: jamesh said that there is support for overriding the error on a per widget basic when using the new LaunchpadFormView
[10:40] <sabdfl> i'd prefer "Help request"
[10:41] <sabdfl> answer request is a... question?
[10:41] <flacoste> so you post 'Help request' in the 'Answer tracker'?
[10:42] <flacoste> sivang: the new official name is 'Answer tracker'
[10:42] <sabdfl> You post a Question in the...
[10:43] <sabdfl> anybody know how to do a LEFT OUTER JOIN in SQLObject?
[10:45] <bradb> kiko: do you know who made the labels bold on the advanced search page
[10:45] <bradb> ?
[10:45] <sabdfl> bradb: annotate?
[10:45] <flacoste> sabdfl: 'Question' was brought up at the sprint, but there was the problem of the generality of that noun, what kind of questions do we see in our 'Answer Tracker'... support question
[10:45] <flacoste> in that sense, i think 'Help request' is better
[10:45] <sabdfl> we're going to see them all...
[10:45] <bradb> sabdfl: did that, but i'm not sure what change to look for
[10:45] <bradb> whether it was css or something else
[10:45] <sabdfl> i expect css, and mpt
[10:46] <kiko> bradb, I think labels have always been bold, and mpt was the one trying to make them non-bold.
[10:46] <bradb> i had them non-bold in the advanced search page
[10:46] <kiko> sabdfl, LEFT OUTER JOINs need to be done manually (though you can use the IN () trick)
[10:46] <sabdfl> IN trick?
[10:47] <sabdfl> can you add a clauseTable of 'Foo INNER JOIN Bar ON x=y'?
[10:47] <kiko> yeah, Foo.select("id IN (random query here)")
[10:47] <kiko> no, using a subselect. not beautiful. but you asked. :)
[10:47] <sabdfl> hmm.... suckiness
[10:48] <sabdfl> niemeyer: can you show me the sample to do a LEFT OUTER JOIN in Storm?
[10:49] <sabdfl> i think it should be Question Tracker
[10:50] <sabdfl>  --> FAQ's pop out naturally
[10:50] <flacoste> and you post a Question in the 'Question Tracker'
[10:50] <flacoste> which makes sense
[10:51] <sabdfl> Ubuntu Linux
[10:51] <niemeyer> sabdfl: Of course..
[10:51] <sabdfl> v6.06 The Dapper Drake
[10:51] <niemeyer> sabdfl: I've implemented it this afternoon.. :-)
[10:51] <flacoste> so we replace the 'Support' facet with 'Question'?
[10:51] <sabdfl> Overview  |  Bugs  | Questions  |  Features  |  Translations  | ...
[10:51] <sabdfl> looks good
[10:52] <sivang> sabdfl: why the move out of the "Support" naming btw ?
[10:52] <sabdfl> 'Questions' plural
[10:52] <sabdfl> sivang: that's the subject we're discussing
[10:52] <niemeyer> sabdfl: store.using(Foo, LeftJoin(Bar, Bar.foo_id == Foo.id)).find(Bar)
[10:52] <sabdfl> because there are other support channels, we don't want to call this "Support"
[10:52] <flacoste> sivang: it meant different things to different people
[10:52] <flacoste> sivang: it was especially confusing with for commercial support option
[10:52] <sabdfl> niemeyer: SOL!
[10:52] <sabdfl> D
[10:53] <sivang> flacoste, sabdfl : ah, I see
[10:53] <sivang> Community Q&A rather
[10:54] <flacoste> sivang: it's a mexican beer
[10:54] <niemeyer> sabdfl: 8-)
[10:55] <sivang> flacoste: then it's gotta be good :p
[10:55] <flacoste> sivang: a little bit like Corona or Eineken - you're usual light refreshing yellow beer
[10:56] <sivang> flacoste: yes, I know Corona. It's very nice.
[10:59] <SteveA> python joke: Bath(None, None)
[11:03] <sivang> flacoste: hmm, no occurences of LaunchpadFormView in my browser/ , how new is this?
[11:04] <flacoste> kiko: has the new jamesh formlib stuff landed yet?
[11:04] <kiko> flacoste, parts of it yes
[11:04] <flacoste> sivang: i must have the wrong class name then
[11:04] <bradb> SteveA: where's the soap?
[11:05] <flacoste> sivang: grep for formlib, that will show you where the base class is defined
[11:07] <flacoste> bradb: here is the link to the patch with nice indentation: https://sodium.ubuntu.com/~andrew/paste/filerSoioS.html
[11:07] <flacoste> flacoste: it's the one that produces the extra white space in front of the bug number
[11:08] <bradb> flacoste: is that change still a go? i tuned out of that conversation.
[11:08] <flacoste> bradb: well, the link bug change is stalled for now
[11:08] <flacoste> bradb: but i could land the checkbox addition in a separate branch
[11:09] <flacoste> bradb: if that is fine with you ... and possibly kiko?
[11:09] <bradb> flacoste: if there's no clear use for it right now, we may want to just leave it
[11:09] <flacoste> bradb: ok, it will get dust with the rest of the branch then
[11:09] <SteveA> bradb: import soaplib  # raises ImportError
[11:09] <flacoste> unless mpt agrees with me that this feature would be a nice addition
[11:10] <bradb> SteveA: i was it expecting "yes, it does, doesn't it"!!
[11:11] <kiko> salgado, 
[11:11] <kiko> you broke +editpgpkeys on staging.
[11:11] <salgado> that's not good
[11:12] <kiko> https://staging.launchpad.net/people/salgado/+editpgpkeys
[11:12] <salgado> how did I break it?
[11:12] <kiko> salgado, copy 27E0 7815 B47C 0397 90D5  8589 27D9 A27B F3F9 6058 into the fingerprint entry
[11:12] <kiko> press go.
[11:12] <kiko> you broke it by not testing it properly. :)
[11:12] <sabdfl> are we running a really old version of sqlobject?
[11:12] <kiko> sabdfl, we're running a branch of a somewhat old version, yes.
[11:14] <sabdfl> hmm... lots of obstacles to updating?
[11:14] <sabdfl> seems there's a join= in the current version
[11:15] <kiko> updating is non-trivial because it requires API changes IIRC
[11:15] <salgado> kiko, I've never touched that code.  care to explain what makes you think I broke it?
[11:16] <kiko> salgado, well, rocketfuel r3853 says you did.
[11:18] <kiko> salgado, are you so sure you /never/ touched that code?
[11:18] <salgado> kiko, yep
[11:18] <salgado>          if key.revoked:
[11:18] <salgado> -            return (
[11:18] <salgado> +            self.error_message = (
[11:19] <salgado> this is what I've done
[11:19] <kiko> salgado, and that broke the page.
[11:19] <kiko> :)
[11:19] <kiko> I'll go up and see with you how to fix it because I have an improvement there to make as well, which is blocked now.
[11:20] <salgado> I blame whoever wrote it for not writing proper tests. :-)
[11:20] <kiko> salgado, you can blame whoever you like as long as you write new tests. :)
[11:21] <bradb> blame the lapin de pque
[11:26] <kiko> nah just old code
[11:27] <cprov> bradb: btw, test failure in your land, can we talk about it ? (pagetests/bugattachments/10-add-bug-attachment.txt)
[11:29] <bradb> cprov: sure. what makes you think a landing can have a test failure? (and what makes you relate that file to a landing of mine?)
[11:30] <salgado> I don't think he meant a code landing
[11:30] <salgado> your land == malone. :)
[11:30] <bradb> oh, the "land" of malone
[11:30] <bradb> heh
[11:30] <cprov> bradb: ehe, malone in general
[11:30] <bradb> when all you have is a hammer, everything looks like a typo
[11:30] <bradb> cprov: so, what's the failure?
[11:31] <cprov> bradb: this line -> link = user_browser.getLink(url='http://localhost:58000/52/foo.txt')
[11:31] <bradb> cprov: can you pastebin the failure output?
[11:31] <cprov> bradb: it changes when other tests added new librarian file in previous tests
[11:32] <cprov> bradb: sure
[11:33] <cprov> bradb: https://sodium.ubuntu.com/~andrew/paste/filew9h2Ar.html
[11:34] <cprov> bradb: right, the fix is very simple, the current LFA.id is 53, because previous test have added a new librarian file.
[11:34] <bradb> ah
[11:34] <sabdfl> kiko: the IN hack ain't too bad
[11:35] <bradb> cprov: bonus points if you can write the test in such a way to cope with the change in IDs, so that a similar change in future wouldn't cause such breakage
[11:35] <bradb> s/write/fix/
[11:36] <cprov> bradb: right, I wonder why getLink("foo.txt") doesn't work. any idea ?
[11:37] <bradb> cprov: if "foo.txt" is the text that one would click on, then no idea
[11:37] <matsubara> there are other labels in that page besides the foo.txt, IIRC
[11:37] <sivang> flacoste: so lib/zope/formlib/ is the place, yes?
[11:37] <flacoste> sivang: that's where formlib is defined, i would expect an import zope.formlib in one file of the launchpad tree
[11:38] <flacoste> sivang: is your rocketfuel up to date?
[11:38] <cprov> bradb: matsubara: ahh -> <a href="http://localhost:58000/53/foo.txt">Some information</a>
[11:41] <cprov> bradb: would you be happy with this approach:
[11:41] <cprov>   >>> link = user_browser.getLink('Some information')
[11:41] <cprov>   >>> link.url
[11:41] <cprov>   'http://localhost:58000/.../foo.txt'
[11:41] <bradb> wooo
[11:41] <bradb> i think that looks good
[11:42] <cprov> bradb: fine, will commit, thank you !
[11:43] <bob__> Hi all, I've added a "release series" by default. Is there anyway to remove it?
[11:43] <bob__> whoops i mean by accident
[11:44] <matsubara> good night all
[11:45] <sivang> flacoste: few weeks old, jamesh's addition is fresh new?
[11:45] <flacoste> sivang: brand new, from yesterday or start of the week
[11:47] <sivang> flacoste: ah, okay.
[11:54] <sivang> night all.
[12:09] <cprov> kiko: have you seen bug #55795 ?
[12:09] <Ubugtu> Malone bug 55795 in launchpad "replaces Debian maintainer by Ubuntu maintainer in changelog" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55795
[12:09] <kiko> nope
[12:09] <cprov> kiko: quick check on https://sodium.ubuntu.com/~andrew/paste/fileUhr5I8.html
[12:09] <cprov> kiko: seems that we are storing broken SPR.changelog 
[12:11] <kiko> I can't see the difference between them
[12:11] <kiko> whose name is wrong?
[12:12] <kiko> oh
[12:12] <kiko> I see now
[12:12] <kiko> how weird.