[12:06] <bradb-afk> i'm still here (though i'm not supposed to be)
[12:06] <dilys> Merge to rocketfuel@canonical.com/sqlobject--test--0.6: [trivial]  Remove SteveA's turd (patch-32: stuart.bishop@canonical.com)
[12:07] <bradb-afk> SteveA: i'd be surprised if it caused that warning, because it's not a slice.
[12:07] <SteveA> it still counts
[12:07] <SteveA> please check it out
[12:07] <bradb-afk> and, futhermore, because i think it's ordered
[12:08] <bradb-afk> (there should be a default ordering imposed, IIRC) checking now
[12:09] <bradb-afk> SteveA: i visited all the +bugs URLs and didn't see the warning. does that mean it's good to go?
[12:09] <bradb-afk> er, one sec
[12:10] <bradb-afk> checked all the task pages too, no warnings.
[12:10] <bradb-afk> SteveA: good to go then?
[12:14] <bradb-afk> SteveA: merge request sent
[12:16] <bradb-afk> what's the magic incarnation to see pqm's queue again? it's gone from my shell history.
[12:16] <elmo> http://pqm.ubuntu.com/
[12:16] <Keybuk> elusive by its obviousness
[12:17] <bradb-afk> ah, didn't know it got moved to a public url
[12:19] <bradb-afk> right, really afk now
[12:21] <Keybuk> bradb-afk: before you go ...
i've left!</out_of_office_reply>
[12:22] <Keybuk> uh-huh
[12:22] <Keybuk> convincing
[12:24] <SteveA> http://sourceforge.net/tracker/index.php?func=detail&aid=1242657&group_id=5470&atid=105470
[12:25] <SteveA> http://python.org/sf/1242657
[12:25] <SteveA> (shortcut to the same thing)
[12:26] <bradb-afk> brutal
[12:26] <bradb-afk> ok, off to mcgill now, mega seriously, mega late
[12:31] <Keybuk> bradb-afk: just one thing ...
[12:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA]  remove IBugTaskSubset (patch-2149: brad.bollenbach@canonical.com)
[12:46] <sabdfl> hey bradb, *great* to see those IBugTaskSubsets disappearing!
[02:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  portlet and page fixes for distroarchrelease (patch-2150: mark.shuttleworth@canonical.com)
[05:47] <XoloX> Hi all. This may be the wrong place to ask, but I'm trying anyway :P. Why is Ubuntu using Bugzilla aswell as Launchpad?
[05:47] <Burgundavia> XoloX, ubuntu is switching over as launchpad is a new product
[05:47] <XoloX> Aha
[05:47] <XoloX> Ok
[05:47] <XoloX> Thanks
[05:47] <Burgundavia> bugzilla was setup for a bug solution now
[05:48] <Burgundavia> launchpad is for a next generation solution, that includes bug handling and other stuff
[05:49] <XoloX> I wanted to file a bug against Galeon from Bugzilla, chose the category Universe, and was redirected to Launchpad where I had to sign up again. I can understand that it's to much trouble to merge the accounts or something like that, but might it be a good idea to provide a small paragraph with an explanation of the situation (Launchpad replacing Bugzilla)?
[05:50] <XoloX> Or maybe I overlooked some FAQ :). Still, it was confusing to me.
[05:50] <Burgundavia> your launchpad login already works on the wiki
[05:50] <Burgundavia> once bugzilla dies, there will only be one ubuntu identify system
[05:51] <XoloX> OK. Thanks for the info!
[05:52] <XoloX> Ehm, one more thing, probably out of context here, but I can atleast try: If I have a problem with Yelp depending on mozilla-firefox, I should file it under Yelp right?
[05:52] <Burgundavia> yes
[05:52] <Burgundavia> and yelp is supported, so that goes in bugzilla
[05:53] <XoloX> Hehe, see what I meant with confusion :P
[05:53] <Burgundavia> bugzilla is for anything is main
[05:53] <XoloX> OK
[05:53] <XoloX> Well, thanks again, cheers
[05:53] <Burgundavia> np
[11:47] <daf> spiv: around?
[11:47] <spiv> daf: yeah
[11:48] <daf> You should not import connect from canonical.database.sqlbase:
[11:48] <daf>     canonical.lp.sql
[11:49] <daf> is this an incomplete __all__ or a bad import?
[11:51] <spiv> Incomplete __all__ I think.
[11:53] <daf> thanks
[12:30] <Kinnison> /srv/launchpad.ubuntu.com/dogfood/launchpad/lib/canonical/archivepublisher/domination.py:135: UserWarning: Getting a slice of an unordered set is unpredictable.
[12:31] <Kinnison> is there an "anyof" operator for the selectresults class?
[12:31] <Kinnison> I just want one of the results, any will do
[12:32] <spiv> Kinnison: Then order by id?
[12:34] <Kinnison> I don't really want to impose any ordering on the select because that'll increase db overhead
[12:35] <Kinnison> but I guess that's the least scary option
[01:02] <spiv> Kinnison: FWIW, iter(results).next() will workaround the warning.  But don't expect reviewers to treat that trick kindly :)
[01:15] <Kinnison> spiv: *sigh*
[01:16] <Kinnison> spiv: having a selectresults.anyof() which effectively did [0]  supressing the warning would be nice
[01:20] <spiv> Kinnison: What's the use case?  So far no-one has had a good reason to want a random row.
[01:32] <spiv> How did you get the packagepublishing records?
[01:32] <carlos> hi
[01:33] <spiv> I'm wondering why you can't directly select an architecture.
[01:36] <Kinnison> spiv: they're passed in as a list of records to be sorted ready for domination
[01:36] <Kinnison> it'll be easier
[01:44] <dilys> New Malone bug 1549 filed on The Launchpad by Matthias Urlichs: System error clicking on "View Changelog"
[01:44] <dilys> https://launchpad.ubuntu.com/malone/bugs/1549
[02:03] <jamesh> interesting post from one of the Gnome developers working for Novell: http://primates.ximian.com/~federico/news-2005-07.html#21
[02:03] <jamesh> sounds like he could really use some of the version control stuff we're working towards
[02:06] <daf> jamesh: he's spot-on about undocumented interfaces, in my opinion
[02:12] <mpt> Not to mention Malone
[02:38] <dilys> Merge to rocketfuel@canonical.com/sqlobject--test--0.6: Force (by using parenthesis) set operations to be applied in the whole SelectResults the method was called. Add tests for this and some other bits of set operations in a separate file. r=spiv (patch-33: guilherme.salgado@canonical.com)
[03:35] <bradb> morning
[03:36] <bradb> No SteveA?
[03:47] <kiko> busy
[03:53] <bradb> SteveA: Hi. Two things: 1. what's new in the world of page titles? 2. you've got mail.
[03:53] <SteveA> hi bradb 
[03:53] <SteveA> cool
[03:53] <SteveA> 1. you can kick my ass when you get to brazil
[03:53] <SteveA> 2. thanks, i'll read the mail
[03:54] <bradb> SteveA: 1. ! 2. ok, cool
[03:59] <salgado> SteveA, I want to run sqlobject's tests on chinstrap, but we need py.test (which is not packaged) for that. should I import it into rocketfuel or package it myself?
[03:59] <SteveA> is that holger krekel's thing?
[04:00] <salgado> yes, it's
[04:01] <mpt> kiko: Do you have time to look at mpt@canonical.com/launchpad--footer--0? There's something missing in either launchpad.zcml or configure.zcml, but I don't know which or what
[04:01] <daf> mpt: what's the error message?
[04:02] <mpt> KeyError: 'legal_should_link'          
[04:02] <daf> hmm, perhaps you can paste something more complete?
[04:03] <mpt> I've specified a new feedback <browser:page> in configure.zcml, like the existing "legal" page
[04:03] <daf> where does the legal_should_link come into it?
[04:03] <mpt> <tal:feedback condition="not: view/feedback_should_link"><a href="/feedback">Give&nbsp;feedback</a></tal:feedback>
[04:04] <mpt> erg, that "not: " shouldn't be there, but anyway
[04:04] <daf> I think you can just do:
[04:04] <daf> <a tal:condition="view/feedback_should_link">...
[04:05] <mpt> oh, true enough
[04:05] <mpt> I don't think that'll fix the underlying problem, though
[04:05] <daf> that doesn't explain why the "legal_should_link" message, though?
[04:05] <daf> s/?//
[04:05] <mpt> I've defined legal_should_link in a "GlobalLinks" class in launchpad.py
[04:05] <SteveA> salgado: let's look at this together in person
[04:06] <mpt> So what I think is happening is that there's somewhere I should be saying "use the GlobalLinks class" and I haven't
[04:06] <daf> mpt: I think you can probably come up with a better name than that :)
[04:06] <salgado> SteveA, sure
[04:06] <mpt> ok, "GlobalNavigationLinks"
[04:06] <daf> no, I mean the _should_link stuff
[04:07] <SteveA> what's this global links thing?
[04:07] <daf> you mean "there should be a link to the feedback page", not "the feedback should link to something"
[04:07] <mpt> the links to the "Legalese" and to the (new) feedback page
[04:07] <mpt> daf: No, because if you're on that page, it'll be <strong>Give feedback</strong>
[04:08] <mpt> It's whether the text should link or not, not whether it should exist at all
[04:08] <daf> urg
[04:08] <daf> this seems like a duplication of the menus logic
[04:08] <mpt> true
[04:08] <mpt> but a menu just for two links in the footer seems like overkill
[04:08] <daf> mmm
[04:09] <daf> what's the view class in this case?
[04:09] <mpt> I don't know. :-)
[04:09] <daf> aha
[04:09] <SteveA> daf: mpt and i will talk about this in person now
[04:10] <daf> sure
[04:10] <mpt> thanks for your time daf
[04:10] <daf> no worries
[04:12] <daf> morgs: yo!
[04:14] <bradb> kiko: so, the best thing i can think of right now to replace <ul tal:condition="python: not request.getURL().endswith('+edit')">, is to move that logic into a method on the ViewWithBugTaskContext method. Still less than ideal, but an improvement on what's currently there, IMHO. Maybe SteveA will have a cleaner solution when he's around.
[04:15] <bradb> s/ViewWithBugTaskContext method/ViewWithBugTaskContext class/
[04:20] <morgs> daf: hi
[04:25] <daf> morgs: can I pick your brain about milestones?
[04:25] <daf> morgs: I'm working on the traversal code
[04:25] <morgs> ok
[04:26] <daf> so, milestones are accessed by /products/foo/+milestones, yes?
[04:27] <morgs> Yes
[04:27] <daf> hmm, as far as I can tell, the only thing you do with milestones is edit them
[04:27] <daf> is that right?
[04:28] <daf> (i.e. /products/firefox/+milestones/1.0/+edit works, but /products/firefox/1.0/ doesn't do anything)
[04:28] <dilys> New Malone bug 1550 filed on The Launchpad by Morgan Collett: Login link to localhost on production on system error page
[04:28] <dilys> https://launchpad.ubuntu.com/malone/bugs/1550
[04:28] <morgs> products/firefix/1.0 would be a product release version 1.0
[04:28] <morgs> s/firefix/firefox/
[04:29] <daf> sorry, I meant /products/firefox/+milestones/1.0/
[04:29] <morgs> Yes, you just edit them, and then they appear in malone
[04:29] <daf> groovy
[04:29] <daf> looks like I'm done, then
[04:29] <morgs> As far as I am aware, there is nothing else you would want to do with them...
[04:29] <morgs> Ok
[04:30] <daf> thanks
[04:30] <daf> bradb: now then, what sort of a beast is a BugTasksReport?
[04:31] <bradb> It's vile. Too bad people keep hacking it, really. It needs a spec.
[04:32] <daf> well, my objective is to work out how not to import it into traversers.py, since it is in the DB code
[04:32] <daf> it's not a DB object
[04:33] <daf> could it perhaps be an adaptor?
[04:33] <daf> on BugTaskSet, maybe?
[04:33] <daf> I'm not clear on what it does
[04:33] <bradb> ok, here's how, i think
[04:33] <bradb> i /think/. you'll have to double check the URL once this is done though
[04:34] <bradb> in traverse_bugs, remove:
[04:34] <bradb>     if name == 'assigned':
[04:34] <bradb>         return BugTasksReport()
[04:34] <bradb>     else:
[04:34] <bradb> and then remove the import
[04:35] <daf> that sounds too simple to be true :)
[04:35] <SteveA> daf: "adapter" please
[04:35] <daf> sorry
[04:35] <bradb> daf: it's probably true
[04:35] <bradb> (i.e. it'll probably work)
[04:35] <daf> well, if the tests pass...
[04:35] <bradb> it's possible that tests will fail
[04:36] <bradb> but that's only because that report exists at two URLs currently, and not one
[04:36] <bradb> the true path is /malone/assigned
[04:36] <daf> noted
[04:36] <bradb> any tests that test /malone/bugs/assigned should instead test /malone/assigned
[04:36] <elmo> uh, someone killed the librarian?
[04:37] <elmo> CRITICAL 22-07-2005 15:31:28 0d 0h 10m 4s 3/3 HTTP CRITICAL: HTTP/1.1 500 Internal Server Error 
[04:37] <daf> Professor Troup, in the Library, with the candlestick
[04:37] <elmo> can it, SAS man.
[04:45] <Keybuk> elmo: the librarian has been killing itself for a while now
[04:45] <Keybuk> spiv did rude things to it
[04:45] <Keybuk> (at least on staging)
[04:45] <elmo> yeah, this is production tho
[05:12] <stub> Oops... production librarian is my faut
[05:12] <stub> I bounced the database because I locked up something I shouldn't have
[05:17] <bradb> SteveA: Just curious, what's the reasoning behind documenting function keyword args like ":foo: bar" instead of, say, "foo -- bar" (the latter being a style borrowed from the example in pep 257)
[05:17] <SteveA> some doc system uses it, some pep uses it somewhere
[05:19] <jamesh> is it reStructuredText format or something?
[05:26] <bradb> Do you guys find this easy to read?
[05:26] <bradb>     Keyword arguments:
[05:26] <bradb>     :from_addr: a string
[05:26] <bradb>     :bugdelta: an IBugDelta
[05:26] <bradb>     :to_addrs: a string, list, or tuple. If a list or tuple, an email
[05:26] <bradb>                is delivered to each recipient individually.
[05:27] <daf> looks reasonable to me
[05:28] <bradb> ok
[05:36] <bradb> stub: Where do I read about the proper way to add a new value to the LP config?
[05:44] <elmo> stub/spiv/stevea: the librarian is up to 100G space usage btw - i can't remember what the cut-off figure you asked for warning was at tho
[05:45] <SteveA> it is in the spec
[05:45] <SteveA> i think .2 TB
[05:45] <SteveA> thanks for the note
[06:00] <carlos> stub, any chance to get the poimport script added to cronscript today?
[06:32] <mpt> bradb: If you're fixing bug 1341, why haven't you accepted it?
[06:32] <mpt> Is it a duplicate?
[06:33] <mpt> (if so, I can't find the original)
[06:35] <carlos> mpt, did you see my question (yesterday) about the missing css code for the po download pages in Rosetta? the language selector looks really ugly
[06:35] <bradb> mpt: because i didn't search for a bug report when i started working on it
[06:36] <carlos> mpt, https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/gnome-panel/+pots/gnome-panel-2.0/+export
[06:36] <mpt> carlos: No I didn't
[06:37] <carlos> mpt, would you fix it, please?
[06:37] <mpt> carlos: sure
[06:37] <mpt> that's a one-line fix
[06:37] <carlos> mpt, cool, thanks
[06:40] <mpt> bradb: Searching Malone needs to be made more attractive, then :-)
[06:41] <bradb> It already is purtier in my menus branch, but that work is being delayed by other refactorings, as requested by SteveA 
[06:42] <bradb> mpt: btw, remind me, did you have an ETA on when you might have a little google-like HTML/CSS snippet that I can plug into the bugtask listing?
[06:42] <mpt> bradb: no, sorry
[06:43] <mpt> pester me when you get here, and I'll do it under your watchful eye
[06:43] <mpt> s
[06:51] <mpt> http://www.google.com/search?q=site%3Awiki.launchpad.canonical.com
[06:53] <elmo> oh, right, I may as well de-SSLize that
[07:00] <elmo> say...
[07:00] <elmo> why did I get:
[07:00] <elmo> R. [  21: The Launchpad Team  ]  Launchpad Account Creation Instructions
[07:00] <elmo> that today?  and how many other people did? :p
[07:07] <carlos> stub, is librarian still down?
[07:08] <carlos> stub, I'm getting emails with errors '500' from librarian
[07:08] <stub> carlos: Oh - I thought elmo had bounced it. I'll bounce it now.
[07:09] <carlos> stub, ok, thanks 
[07:09] <stub> carlos: Should be fine now
[07:09] <carlos> ok
[07:09] <carlos> could you take a look at the poimport script please? :-)
[07:10] <carlos> now that you are connected...
[07:21] <Kinnison> See you all on Sunday/Monday
[07:22] <Kinnison> kiko: Will anyone meet me at the bus station on Sunday, or should I wander up to the hotel on my own?
[07:22] <Kinnison> kiko: Or indeed should I come and bang on your front door?
[07:23] <kiko> Kinnison, what time do you arrive?
[07:26] <Kinnison> kiko: plane lands at 0510 as per the wiki
[07:26] <Kinnison> Other than that, I dunno, I imagine out of the airport by 0600, so hitting SC around 1000 ?
[07:31] <salgado> SteveA, might you have some time to look at my changes in basicvoting (https://chinstrap.ubuntu.com/~jamesh/pending-reviews/guilherme.salgado@canonical.com/launchpad--basic-voting--0/filtered-diff) today?
[07:35] <kiko> Kinnison, prolly
[07:36] <stub> carlos: poimport reenabled as per email
[07:37] <carlos> stub, thank you
[07:37] <guillem> hola com va tot?
[07:38] <kiko> not bad
[07:38] <carlos> guillem, hi
[07:44] <guillem> hi carlos
[07:45] <guillem> de donde eres?
[07:47] <kiko> m/f?
[07:50] <carlos> guillem, este canal es de habla inglesa, la mayora no entienden espaol.
[07:53] <mpt> elmo: Oh, that was my fault, sorry
[07:53] <mpt> elmo: Someone was asking me about the "merge accounts" page, and trying to find it, and we guessed that you wouldn't have a Launchpad account, but you did, or vice versa
[07:53] <elmo> ok, that's cool as long as it wasn't to _everyone_ ;-)
[07:59] <bradb> salgado: did you see my reply to your code review of one-bugmail-per-recip?
[08:05] <salgado> bradb, yep
[08:06] <Keybuk> it was a "what happens if we do X?  Does anyone know someone who won't have added himself to launchpad yet?" kind of thing
[08:09] <salgado> bradb, you use Mail-followup-to: header because you want the replies going to the list but not you?
[08:10] <kiko> I HATE THAT HEADER
[08:10] <bradb> salgado: yes; getting two emails just annoys the heck out of me
[08:11] <Keybuk> why does Malone send e-mails as "Blah but really Malone <xxx@malone>" ?
[08:11] <Keybuk> can't it use headers properly, and do
[08:11] <Keybuk> From: Blah <blah@blah.com>
[08:11] <Keybuk> Sender: Malone <admin@malone.com>
[08:11] <Keybuk> Reply-To: Malong bug X <xxx@malone>
[08:12] <bradb> if I were lazier, I'd setup my filtering to autokill the second message just in case
[08:16] <stub> BjornT: Is there a reason you decided to use the From: address instead of the Reply-To: to get replys to Launchpad? I know Roundup does both for some reason, but I think Keybuk's suggestion would be fine.
[08:17] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-51)
[08:17] <mpt> arg
[08:17] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.5: safe_flush at the end of arch_print_headers_summary, display revision info as soon as possible in archive-mirror (patch-40: Matthieu.Moy@imag.fr)
[08:18] <mpt> After I've done a "make clean" on Launchpad, how do I get it running again?
[08:18] <kiko> make build iirc
[08:18] <kiko> and then make run
[08:18] <kiko> make schema and make run
[08:18] <mpt> thanks
[08:18] <kiko> so carlos, daf?
[08:19] <kiko> ProgrammingError: ERROR:  permission denied for relation translationgroup
[08:19] <kiko> carlos, daf: I've asked stub to fix up permissions for that table for the poimport user -- unless you scream
[08:19] <bradb> stub: I designed/implemented the From: header. Relied on the From: header because Reply-To seemed unnecessary.
[08:19] <stub> I'll update it on production but would like someone to update security.cfg and merge it as [trivial] 
[08:20] <carlos> stub, I will do it
[08:20] <kiko> salgado, how do you make mutt ignore that header?
[08:20] <kiko> hmmm
[08:20] <carlos> stub, the tests didn't detect it because the transaction problems spiv is working on
[08:20] <kiko> bradb, stub, what do you think of Keybuk's suggestion?
[08:20] <mpt>     ImportError: No module named gettextpo
[08:20] <mpt> *** ERROR: Trebuchet died prematurely!
[08:20] <mpt> kiko, that didn't work
[08:20] <bradb> kiko: it's described why we didn't do that in the spec
[08:20] <bradb> kiko: it seems a bit confusing, IMHO
[08:20] <kiko> bradb, point dear Keybuk to the spec then
[08:20] <salgado> kiko, I don't do that. neither I know if it's easy
[08:21] <bradb> Keybuk: from the spec:
[08:21] <kiko> btw
[08:21] <bradb> The From: header will contain the name of the person that made the change. It is intended to help someone scanning their Inbox to "weight" each mail. We intend for users to take advantage of the X-Malone-BugXXX headers to filter and sort their mail if they want to, but being able to quickly scan your "critical" folder for reports from your manager can be quite useful. :)
[08:21] <bradb> It's also intended to be clear that this email came through Malone ("...via Malone") and show the email address that will be replied to, rather than confusing the user with Reply-To trickery. 
[08:26] <Keybuk> that doesn't say why you're not doing that
[08:26] <Keybuk> it just says that you're not
[08:26] <carlos> stub, the poimport security entry is completely empty??
[08:27] <bradb> Keybuk: "rather than confusing the user with Reply-To trickery." is a hint :)
[08:27] <Keybuk> I've never seen a user confused by Reply-To
[08:27] <bradb> "show the email address that will be replied to", etc.
[08:27] <Keybuk> show the e-mail address is a misnomer, most modern mail clients *HIDE* the e-mail address
[08:27] <kiko> stub, carlos, daf: translator also needs permissions.
[08:28] <stub>  And a test that runs the script, connecting as the correct user.
[08:28] <Keybuk> so you're going to confuse the user by making them think they're replying to the submitter, not Malone
[08:28] <carlos> kiko, any table we use will need permissions, as I said, it's empty :-?
[08:28] <kiko> carlos, could you list the tables to stub, then, please?
[08:28] <carlos> stub, I told you already that I had to disable that test because transaction problems
[08:28] <mpt> Can anyone tell me how to unbreak my Launchpad?
[08:28] <mpt> Sorry to be such a millstone
[08:28] <carlos> stub, spiv is working on it
[08:28] <kiko> ah
[08:29] <Keybuk> (you just confused me, you see, and I don't consider myself an idiot user :p)
[08:29] <bradb> Keybuk: isn't that was "via Malone" is for?
[08:29] <jamesh> mpt: is the GlobalLinks class in your branch meant to be used?
[08:29] <Keybuk> I assumed that meant it came from Malone, not that my reply would go to Malone
[08:29] <carlos> stub, is there an easy way to get the list of tables the script needs?
[08:29] <mpt> jamesh: no, I should have removed that
[08:30] <carlos> stub, is it possible that you were executing that script as the poexport user?
[08:30] <bradb> Keybuk: where did you think your reply would go to?
[08:30] <Keybuk> the original submitter only
[08:31] <Keybuk> I actually hunted for a few seconds in the e-mail to find out how to copy that into malone
[08:31] <Keybuk> and then noticed the From: address was mangled
[08:31] <carlos> it makes no sense that it does not have any right, we executed it before...
[08:32] <mpt> Keybuk: How much do you use Bugzilla?
[08:32] <Keybuk> occasionally
[08:33] <bradb> Keybuk: hm, interesting. you're the first person to have mentioned being confused by this. which is not meant to suggest that obviously it's not a problem, but rather that i'd be curious to see what some proper user testing of the email notifications would discover, before we change anything just yet.
[08:33] <mpt> All Bugzilla mail comes from bugzilla-daemon@whatever
[08:33] <Keybuk> bugzilla doesn't have a mail-reply-to-comment thing though, does it?
[08:33] <mpt> no matter who caused the change, and no matter what bug
[08:33] <Keybuk> I've always gone to the web page to reply
[08:33] <jamesh> mpt: unleess the admin has changed the from: address
[08:33] <stub> carlos: env LPCONFIG=production PYTHONPATH=$HOME/dists/launchpad/lib LP_DBUSER=poimport LP_DBNAME=launchpad_prod LP_DBHOST=emperor python $HOME/dists/launchpad/cronscripts/rosetta-poimport.py -q
[08:33] <mpt> Keybuk: sure, but that's not your use case here, your use case is sending mail to the person who made the change
[08:33] <jamesh> mpt: I've seen some with bugzilla@...
[08:33] <mpt> Neither Bugzilla nor Malone let you do that
[08:34] <Keybuk> when I get an e-mail from a BTS with some text in it, I want to be able to reply to it
[08:34] <Keybuk> to reply to the comments that person makes
[08:34] <Keybuk> the headers of the incoming e-mail should be set up to make it obvious that the reply is going to be copied into the bug tracking system
[08:34] <mpt> fair enough, I occasionally do that too (usually to say "that comment probably wasn't helpful)
[08:34] <mpt> but the most common case is adding a comment to the bug itself
[08:34] <Keybuk> using the standard From (person who wrote the comment), Sender (automatic system that generated the e-mail) and Reply-To (where your reply will go) headers would accomplish that
[08:35] <Keybuk> right
[08:35] <Keybuk> so I expect that replying to a mail from $BTS should add a comment to the bug itself
[08:35] <mpt> Is this the Reply-To-Munging-Considered-Harmful flamewar in disguise?
[08:35] <mpt> I think it is
[08:35] <jamesh> mpt: we aren't munging emails -- we are generating them
[08:35] <Keybuk> Reply-To is harmful for mailing lists, not ordinary use
[08:35] <carlos> grrr
[08:35] <kiko> I was about to say that.
[08:35] <kiko> carlos?
[08:36] <carlos> I forgot to remove the automatic imports from the notifictions
[08:36] <carlos> daf, be prepared, we are being spammed...
[08:36] <Keybuk> From: Matthew Paul Thomas <mpt@canonical.com>
[08:36] <Keybuk> Sender: Malone <malone@launchpad.ubuntu.com>
[08:36] <Keybuk> Reply-To: Malone Bug 1488 and Matthew Paul Thomas <1488@bugs.launchpad.ubuntu.com>
[08:36] <Keybuk> -- 
[08:36] <Keybuk> would be how I'd do the headers
[08:37] <Keybuk> From mpt, really sent by Malone and replies go to the magic address that sends to both
[08:37] <mpt> ok, so what would a "Reply" button do?
[08:37] <Keybuk> reply would go to the Reply-To address
[08:37] <Keybuk> Reply-To overrides From, From overrides Sender
[08:37] <mpt> so some mailers have a special "reply to author" function?
[08:37] <Keybuk> this is spelled out very clearly in the RFC, and I've never seen a non-compliant mail client
[08:38] <kiko> carlos, automatic imports?
[08:38] <mpt> Thunderbird is sorta non-compliant because it refers to From as "Sender" in its UI
[08:38] <Keybuk> some mailers do provide a "reply to the From, ignoring Reply-To or Mail-Followup-To" function
[08:38] <mpt> ok
[08:38] <carlos> kiko, hoary imports
[08:38] <Keybuk> and, in my example, that button becomes useful
[08:38] <Keybuk> because I can deliberately reply to you, in private, to avoid mail going to the list
[08:38] <mpt> that seems reasonable, bradb?
[08:38] <carlos> kiko, the po imports are being executed so we are getting confirmation emails
[08:38] <Keybuk> uh, s/list/bug/
[08:38] <bradb> salgado: replied to your reply. do i get my r=salgado now? :P
[08:38] <Keybuk> where in the current system, I can't do that ;)
[08:38] <carlos> kiko, s/hoary/breezy/
[08:39] <kiko> I think Keybuk is correct.
[08:41] <bradb> hm
[08:41] <bradb> Of the headers mentioned, I only show From: in my mutt configuration
[08:43] <bradb> You might be right, but I'll note that: 1. you'd be less confused but I'd be more confused and 2. would it be a good idea to user test this on a couple more people before we change functionality that has only recently been released?
[08:45] <bradb> One other thing I was curious about: when's the last time you guys replied to an email where the address that was replied to was a different address than the From: address of the email? What about Normal People? Is it something they'd be used to?
[08:46] <kiko> I think so
[08:49] <Keybuk> the mutt default config includes reply-to
[08:49] <Keybuk> (me just checks)
[08:50] <Keybuk> checked
[08:50] <kiko> bradb, I think Keybuk is right, and moreover, stub does too.
[08:51] <salgado> bradb, it should be good to go now.
[08:51] <mpt> bradb: (1) The current behavior hasn't been user-tested either, and (2) I doubt this is the sort of thing you could user test at all
[08:53] <bradb> mpt: 1. exactly my point ;) as to whether it's testable or not, i'm not really sure
[08:54] <bradb> do you guys have an example of a threaded email discussion where the From: address and the Reply-To: are different?
[08:56] <Keybuk> From: 	Vagrant Cascadian <vagrant+bugs@freegeek.org>
[08:56] <Keybuk> Reply-To: 	Vagrant Cascadian <vagrant+bugs@freegeek.org>, 319421@bugs.debian.org
[08:56] <Keybuk> Sender: 	Debian BTS <debbugs@bugs.debian.org>
[08:56] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Minor cleanups to database/potemplate.py, and a lint.sh fix (patch-2151: christian.reis@canonical.com)
[08:58] <bradb> looking at my RSS feeds in tbird, i only see the From: address
[08:59] <bradb> so, there's this notion with transactional email being a customer service representative
[09:00] <bradb> the From: field of a transactional email should show two things:
[09:00] <bradb> 1. a recognizable brand name
[09:00] <bradb> 2. something to distinguish this email from spam
[09:00] <bradb> if we make this change and i file a bug
[09:00] <bradb> i'm going to get a bugmail
[09:00] <bradb> From: Brad Bollenbach <brad.bollenbach@ubuntu.com>
[09:01] <mpt> from "Brad Bollenbach"
[09:01] <mpt> a highly suspicious name
[09:01] <bradb> if i ever get an email from "Brad Bollenbach", yes, i'm going to be highly suspicious :)
[09:02] <mpt> bradb, if you're receiving bugmail when a bug is *reported*, it's because you're involved in software development, which means you're almost certainly on one or more development mailing lists, which means you're getting e-mail from random strangers all the time
[09:02] <bradb> so, does a From: Brad Bollenbach <brad.bollenbach@ubuntu.com> achieve both the stated objects? (as per Jakob Nielsen's words, not mine, but that doc was a foundation of the design)
[09:03] <mpt> And if you're getting bugmail at any other time, it's either because the bug has been reassigned to you, which means you're involved in software development, etc; or it's because you've subscribed to the bug, in which case you recognize the subject line.
[09:04] <Keybuk> personally, spam-wise, I'd fine
[09:04] <Keybuk> uh, find...
[09:04] <Keybuk> From: Brad Bollenbach <brad.bollenbach@ubuntu.com>
[09:04] <jamesh> mpt: or if someone else asks a question about a bug you openned?
[09:05] <Keybuk> non-suspicious (ish)
[09:05] <Keybuk> but
[09:05] <Keybuk> From: Brad Bollenbach <an-email-address-that-isn't-brad's>
[09:05] <bradb> Keybuk: sure, but if it were an email from yourself?
[09:05] <Keybuk> suspicious
[09:05] <mpt> jamesh: That == you're subscribed (in the Malone model)
[09:05] <Keybuk> bradb: I'd expect an e-mail to be Scott James Remnant <scott@netsplit.com>
[09:05] <bradb> Keybuk: agreed, hence the "via Malone" bit, which you've already said tells you it came from malone
[09:05] <mpt> (so I should have said "you're", rather than "you've"
[09:05] <Keybuk> not an e-mail address that isn't mine
[09:05] <jamesh> mpt: ah.  That's "you're subscribed" rather than "you've subscribed"
[09:05] <mpt> jamesh: snap.
[09:05] <Keybuk> but that's abusing things for which there are perfectly good additional headers
[09:06] <Keybuk> I guess you're worry is that you might be exposing your e-mail address to spam harvesters?
[09:06] <mpt> bradb: "... via Malone" is often hidden beyond the ellipsized part of the From address in the list pane of my mail clients
[09:06] <jamesh> we already expose email addresses, don't we?
[09:06] <bradb> mpt: yup
[09:07] <kiko> jamesh, to logged in users
[09:07] <bradb> so, the other part is: does: Brad Bollenbach <brad.bollenbach@ubuntu.com> contain a recognizable brand name?
[09:07] <Keybuk> if someone's getting an e-mail FROM malone, aren't they by definition someone with a Malone account? :p
[09:08] <jamesh> kiko: okay.  and anyone receiving a bug mail would have been an authenticated user in order to subscribe to the bug ...
[09:09] <bradb> Keybuk: And after the recognizable brand name question, there was another thing I was curious about: looking at a bugmail in this way in tbird, how do i actually know that the bugmail even came from Malone at all until i hit reply (and even then, do i know?)
[09:09] <Keybuk> why do you care?
[09:09] <Keybuk> tbird should at least show the Reply-To ?
[09:09] <Keybuk> which will have MALONE in it
[09:09] <bradb> Keybuk: because I want to know that it came from Malone :)
[09:09] <mpt> bradb: This is a bug tracker, not buylotsofstuffwithoneclickshopping.com
[09:10] <Keybuk> you do ?!
[09:10] <Keybuk> put it in the e-mail body :P
[09:10] <bradb> Keybuk: the more we shove in the body, the more litter in replies
[09:10] <jamesh> bradb: isn't the Launchpad branding in the URL enough?
[09:10] <Keybuk> I don't think that belongs in From:
[09:10] <bradb> jamesh: yup, but you have to be able to see it, right? :)
[09:11] <bradb> jamesh: or, otherwise, be given some hint in some way (e.g. "via Malone", whatever)
[09:11] <mpt> bradb: Ok, if you want branding in the From, make it 12345@malone.launchpad.net.
[09:11] <jamesh> bradb: it's in the second line of the email ...
[09:11] <bradb> mpt: yep
[09:11] <mpt> oh, wait, that's not the author's address
[09:11] <mpt> ha
[09:11] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-52)
[09:12] <bradb> jamesh: users won't even get that far if the email looks spammish
[09:12] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.5: fixed a segfault in baz archive-version (patch-41: Matthieu.Moy@imag.fr)
[09:12] <bradb> do you base your email filters on Reply-To or From, for example?
[09:13] <Keybuk> personally?  neither
[09:13] <Keybuk> but in general, From:
[09:13] <Keybuk> and if Malone was circumventing my Brad Bollenbach killfile, I'd be very upset with it <g>
[09:13] <mpt> haha
[09:15] <bradb> hm, this is all sounding a bit far-fetched to me so far
[09:15] <jamesh> bradb: if users start assuming that emails with senders of the form "foo bar via Malone" and we get popular, I can guarantee that we won't be the only people sending emails of that form :)
[09:15] <Keybuk> for reference, procmail's filters check sender, from and to
[09:15] <Keybuk> uh, reply-to
[09:16] <mpt> "via" doesn't seem a very robust way of inventing new headers
[09:17] <Keybuk> plus the rfc already gives you perfectly servicable headers for this :p
[09:18] <bradb> I'm trying desparately to convince myself that it's a good thing that a From: address in no way indicates this email is connected to Malone.
[09:19] <kiko> bradb, turn it around. try to convince /us/ that there is a need for the from address to indicate the mail comes from malone.
[09:19] <kiko> bradb, remember that there is a [bug XXX]  bit in the subject
[09:19] <Keybuk> (and read  3.6.2 of RFC 2822 :p)
[09:19] <mpt> bradb: And don't refer to people who are talking about e-commerce :-)
[09:19] <bradb> kiko: http://www.useit.com/alertbox/20031208.html, in particular, this passage:
[09:20] <bradb> In most cases, the from field should clearly show two things: a recognizable brand name (if available), and a function that clearly distinguishes the message as a transaction rather than an advertisement. In our study, effective senders included reservations@hilton, tickets@amtrack.com, and ship-confirm@amazon. Note that most of these from lines were truncated by the in-box view: you typically have no more than 20 characters to conv
[09:20] <mpt> bradb, what did I just say? :-P
[09:20] <bradb> kiko: [Bug 42]  foo, doesn't give any hint that it's from Malone
[09:20] <bradb> could just as well be from bugzilla or somewhere else.
[09:20] <mpt> bradb: How about "[Malone bug 42] ?
[09:21] <Keybuk> bradb: those are for totally automatic messages though
[09:21] <Keybuk> your messages are retransmissions of an e-mail or comment supplied by an author
[09:21] <bradb> mpt: it's only Malone bug 42 if it's bug #42 on Malone, right?
[09:21] <Keybuk> btw
[09:21] <Keybuk> those three things happen to be in my killfile ;P
[09:22] <mpt> bradb: Only if the same applies to "via Malone"
[09:22] <bradb> mpt: also, microcontent. do we have room for "[Malone..." at the beginning of every subject line?
[09:22] <mpt> bradb: No we don't, kiko's just jumped on me for that
[09:22] <bradb> Keybuk: not necessarily.
[09:23] <bradb> Keybuk: could have been a status change, adding an external link, setting a bug private, etc.
[09:23] <Keybuk> right, so _those_ e-mails should be From: Malone ...
[09:23] <Keybuk> seriously, look at debbugs, it does this exactly right
[09:24] <Keybuk> because it's had ten years of people who know how e-mail systems should and must work making absolutely sure it does
[09:24] <Keybuk> your argument seems to be that some random e-commerce spam site says you should put Malone branding in the From address
[09:25] <bradb> Keybuk: dude, you also think that three bug statuses exactly right. :) there are non-power-users involved here too, right? :)
[09:25] <Keybuk> mine is that you're giving the recipient more power by using the headers properly
[09:25] <Keybuk> uh, I think there are _two_ bug statuses; "open" and "closed" :p
[09:25] <bradb> oh yeah, heh :)
[09:26] <Keybuk> separating the original author and autonomous system allows me to make a choice
[09:26] <Keybuk> I can hit "reply" and send it to the autonomous system (in Reply-To)
[09:26] <Keybuk> or I can "reply to author" and send a private mail to the person who made the comment
[09:26] <Keybuk> the Sender header clearly identifies the mail as been generated by malone
[09:27] <bradb> mpt: so, from a usability perspective, you think it's a good thing that that the From: address *not* in any way indicate that this email came from Malone?
[09:27] <mpt> bradb: No, I don't think it's a good thing, but I think the current approach causes other problems that are worse overall.
[09:27] <bradb> as if life weren't already difficult enough for MLM's with the bugmail from address :)
[09:28] <bradb> mpt: such as?
[09:28] <mpt> bradb: Such as not being able to reply to the commenter without a fiddly copy-and-paste work.
[09:29] <Keybuk> or allowing people to use Malone to e-mail people who have killfiled them
[09:29] <bradb> Keybuk: this change won't really change that
[09:29] <bradb> Keybuk: remember, people can add comments when they make other changes
[09:30] <Keybuk> those should be From: person-who-made-the-change
[09:30] <Keybuk> so I can reply to it to ask them why
[09:31] <mpt> bradb: If a confirmation from a Nielsen-hiring e-commerce site to you gets lost, that's their loss. If a Malone message to you gets lost, that's your loss and yours alone. You have an interest in ensuring you get Malone mail, and we're not making it particularly hard to get such mail.
[09:32] <bradb> i concede that the not-being-able-to-reply directly easily is an annoying problem, but i'm not sure that i agree that that's even worse than not knowing that the email came from Malone
[09:32] <Keybuk> you know the e-mail came from Malone
[09:32] <bradb> Keybuk: how?
[09:32] <Keybuk> assuming you're not using a broken mail client (<g>) you can see the Sender: header
[09:32] <Keybuk> and the SECOND LINE in the e-mail says malone
[09:33] <Keybuk> and the Reply-To (which your e-mail client is _very_ broken if it's hiding) says Malone
[09:33] <bradb> Keybuk: dude, inside the body is too late :) the point is to make it clear to someone swimming through their inbox.
[09:33] <Keybuk> in the summary view, the fact it begins [Bug XXXX]  is a bit of a hint that it comes from Malone, or some other BTS
[09:33] <kiko> I agree with Keybuk 
[09:33] <bradb> looking at tbird, it appears to me to be just showing From:, but maybe i'm doing something wrong
[09:33] <Keybuk> personally, I tend to search on the XXXX as the duplication between different systems that e-mail me is low
[09:34] <Keybuk> the chances are the "via Malone" bit is going to get truncated off ANYWAY in the summary view
[09:35] <Keybuk> [Bug XXX]  is the summary hint
[09:35] <bradb> in my default tbird view i don't think it would
[09:35] <bradb> Keybuk: not if you're already using 2 other bugzilla instances, right?
[09:35] <Keybuk> bradb: don't you have one of those mad widescreen ultra-hi-res laptops though? :p
[09:35] <Keybuk> bradb: I use debbugs and several bugzillas every day, and have still never got the same XXX bit
[09:35] <Keybuk> I just filter my mailbox on the Bug#
[09:35] <Keybuk> I don't think about which BTS/Bugzilla/etc. it came from
[09:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=salgado]  change bugmail notification to one bugmail per recipient (patch-2152: brad.bollenbach@canonical.com)
[10:04] <kiko> carlos?
[10:04] <kiko> or daf?
[10:16] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=stub]  fix up security permissions for my stuff (patch-2153: scott@canonical.com)
[10:19] <SteveA> bradb: ping
[10:32] <jordi> hey
[10:32] <jordi> carlos
[10:32] <jordi> hmm
[10:37] <mpt> jamesh: Did you want me to remove that stray class before you re-review the footer branch?
[10:38] <SteveA> spiv: ping
[10:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=stub]  fix up security permissions for my stuff (patch-2154)
[10:46] <jamesh> mpt: I hadn't actually started reviewing it -- just took a quick glance
[10:59] <Keybuk> SteveA: is Launchpad "Plone" or "Zope 3" ?
[11:03] <SteveA> what does that mean?
[11:03] <Keybuk> <-- he asked
[11:03] <Keybuk> I thought it was a Plone app written with Zope 3
[11:03] <Keybuk> or something
[11:04] <Keybuk> but then I confuse Plone, Zope and Twisted all the time
[11:04] <SteveA> we are borrowing the plone CSS stylesheet
[11:04] <SteveA> that is all of plone there is in there
[11:04] <Keybuk> right
[11:04] <Keybuk> so what's Plone?
[11:04] <SteveA> plone.org
[11:04] <Keybuk> I thought Plone was a webapp framework on Zope?
[11:04] <SteveA> it is a content management system built on zope2
[11:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  More lintage fixes, and FINALLY make lint.sh work with python files (patch-2155: christian.reis@canonical.com)
[11:22] <bradb> gotta step out for a bit, back later
[11:43] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=kiko, rs=sabdfl]  add dummy 'Code branches' page for each person (patch-2156: mpt@canonical.com)