[17:52] <kiko> em
[17:55] <Rinchen> you're a few minutes early ;-)  But I like your spirit!
[17:58] <Rinchen> I like the userlist on the channel. Much better than last week
[17:59] <thumper> Rinchen: appologies from mwhudson (holiday)
[17:59] <Rinchen> roger that....
[17:59] <Rinchen> well, let's fire it up
[17:59] <Rinchen> #startmeeting
[17:59] <MootBot> Meeting started at 19:00. The chair is Rinchen.
[17:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:59] <Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
[17:59] <Rinchen> [TOPIC] Roll Call
[17:59] <MootBot> New Topic:  Roll Call
[17:59] <bigjools> me
[18:00] <sinzui> me
[18:00] <mrevell> me
[18:00] <Rinchen> me
[18:00] <kiko> me
[18:00] <herb> me
[18:00] <barry> me
[18:00] <thumper> me
[18:00] <mpt> me
[18:00] <mars> me
[18:00] <al-maisan> me
[18:00] <adeuring> me
[18:00] <allenap> me
[18:00] <Rinchen> apologies from  statik, bac, and mwh
[18:00] <intellectronica> me
[18:00] <mthaddon> me
[18:00] <matsubara> me
[18:00] <BjornT> me
[18:00] <kiko> and gmb
[18:00] <danilos> me
[18:00] <schwuk> me
[18:00] <Rinchen> EdwinGrubbs?
[18:00] <jtv> me
[18:01] <Rinchen> cprov?
[18:01] <jtv> carlos?
[18:01] <EdwinGrubbs> me
[18:01] <Rinchen> jml?
[18:01] <abentley> me
[18:01] <carlos> me
[18:01] <thumper> Rinchen: no jml
[18:01] <Rinchen> oh, jml is  asleep that's right
[18:01] <Rinchen> SteveA?
[18:01] <flacoste> me
[18:01] <Rinchen> salgado?
[18:02] <salgado> me
[18:02] <Rinchen> nifty
[18:02] <Rinchen> [TOPIC] Agenda
[18:02] <MootBot> New Topic:  Agenda
[18:02] <Rinchen>  * Next meeting
[18:02] <Rinchen>  * Actions from last meeting
[18:02] <Rinchen>  * Oops report (Matsubara)
[18:02] <Rinchen>  * Critical Bugs (Rinchen)
[18:02] <Rinchen>  * Bug tags
[18:02] <Rinchen>  * Operations report (mthaddon/herb)
[18:02] <Rinchen>  * DBA report (stub)
[18:02] <Rinchen>  * Sysadmin requests (Rinchen)
[18:02] <Rinchen>  * New packages required (salgado)
[18:02] <Rinchen>  * A top user-affecting issue (mrevell)
[18:02] <Rinchen>  * Doc Team report (mrevell)
[18:02] <Rinchen> * What environments use zopeless mode and require send_email: true (sinzui)
[18:02] <Rinchen> * LaunchpadValidationError and HTML escaping (intellectronica, kiko)
[18:02] <cprov> me
[18:02] <Rinchen> * Blockers
[18:03] <Rinchen> [TOPIC] Next meeting
[18:03] <MootBot> New Topic:  Next meeting
[18:03] <Rinchen> we have an action item on this
[18:03] <Rinchen> kiko - consider changing meeting time after April 6th.
[18:03] <danilos> translations team is sprinting
[18:03] <kiko> it's not april 6th yet!
[18:03] <Rinchen> Just a reminder :-)
[18:04] <Rinchen> [ACTION] kiko - consider changing meeting time after April 6th.
[18:04] <MootBot> ACTION received:  kiko - consider changing meeting time after April 6th.
[18:04] <kiko> thanks
[18:04] <Rinchen> So, next week, same time, same location
[18:04] <kiko> I love this location
[18:04] <Rinchen> nice isn't it? :-)
[18:04] <thumper> could be better
[18:04] <Rinchen> [AGREED] next week, same time, same location
[18:04] <MootBot> AGREED received:  next week, same time, same location
[18:05] <Rinchen> [TOPIC]  Actions from last meeting
[18:05] <MootBot> New Topic:   Actions from last meeting
[18:05] <Rinchen> matsubara to email thumber the code oops
[18:05] <danilos> Rinchen: note that jtv, carlos, danilo will be sprinting, perhaps missing the meeting (not necessarily, but very well could be busy next week)
[18:05] <matsubara> Rinchen: I've assigned thumper to the bug instead
[18:05] <Rinchen> danilos, we'll find you.  *evil laughter*
[18:05] <Rinchen> thank matsubara
[18:05] <danilos> Rinchen: ;)
[18:05] <Rinchen> [TOPIC] Oops report (Matsubara)
[18:05] <MootBot> New Topic:  Oops report (Matsubara)
[18:05] <matsubara> I have only one new oops to report. Filed as bug 207818
[18:05] <ubotu> Launchpad bug 207818 in malone "Change bug watch form needs better validation when a non-URL is entered" [Undecided,New] https://launchpad.net/bugs/207818
[18:06] <matsubara> BjornT, it's a rare occurance (happened only 3 times) but it'd be nice to have it fixed. Is it possible to schedule a fix for the next week 0?
[18:06] <Rinchen> which is next week
[18:06] <matsubara> exactly :-)
[18:06] <BjornT> matsubara: yes, that should be possible.
[18:07] <matsubara> tomorrow I'll follow up with the teams if there are any new OOPSes after the release
[18:07] <Rinchen> [AGREED] Bjorn to attempt to schedule bug 207818 for the next week 0
[18:07] <MootBot> AGREED received:  Bjorn to attempt to schedule bug 207818 for the next week 0
[18:07] <ubotu> Launchpad bug 207818 in malone "Change bug watch form needs better validation when a non-URL is entered" [Undecided,New] https://launchpad.net/bugs/207818
[18:07] <matsubara> btw, oops.cgi is broken and I'm fixing it.
[18:07] <matsubara> thanks BjornT
[18:07] <matsubara> apart from that, I'm done. back to you Rinchen
[18:07] <Rinchen> thanks
[18:07] <Rinchen> [TOPIC] Critical Bugs (Rinchen)
[18:07] <MootBot> New Topic:  Critical Bugs (Rinchen)
[18:07] <Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/196936
[18:07] <Rinchen> abel, how is this going? This is now about three weeks old. Perhaps this should be high and not critical?
[18:07] <MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/196936
[18:08] <Rinchen> adeuring ^^
[18:08] <adeuring> Rinchen, I'm waiting for the review ...
[18:08] <kiko> adeuring, waiting for 3 weeks? :)
[18:08] <adeuring> kiko: well, one week
[18:08] <Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/207490
[18:08] <Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/207494
[18:08] <Rinchen> allenap, you're working on these as release critical yes? Can we help any way?
[18:08] <MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/207490
[18:08] <MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/207494
[18:08] <Rinchen> help IN any way that is
[18:09] <allenap> Rinchen: intellectronica finished the second one off and they're in PQM afaik.
[18:09] <Rinchen> allenap, sweet thanks
[18:09] <Rinchen> adeuring, do you need a reviewer for it? I hear from a good source that salgado is today's on-call reviewer
[18:09] <adeuring> It is already on Curtis's queue
[18:10] <kiko> adeuring, why didn't you use on-call?
[18:10] <kiko> adeuring, it's completely unacceptable for a patch to go for a week with no review
[18:10] <kiko> and it's not anybody's fault but yours -- you need to find somebody to review it, not idly wait for it to happen
[18:10] <adeuring> kiko: yes, right...
[18:10] <kiko> please follow up with an on-call reviewer
[18:10] <kiko> this was critical..
[18:10] <adeuring> kiko: OK
[18:10] <kiko> anyway
[18:11] <Rinchen> [TOPIC] Bug tags
[18:11] <MootBot> New Topic:  Bug tags
[18:11] <Rinchen> we have two
[18:11]  * sinzui hangs head in shame for not seeing it
[18:11] <Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
[18:11] <Rinchen> spurious-test-failure by kiko and BjornT
[18:11] <Rinchen> we skipped this last week since both of you were absent
[18:11] <kiko> well, look at that -- a candidate :)
[18:11] <thumper> it's a tad long isn't it?
[18:12] <kiko> thumper, and?
[18:12] <kiko> I mean, it's /good/ that it's long
[18:12]  * thumper shrugs
[18:12] <Rinchen> what purpose would this solve over simply using the test-system tag?
[18:12] <kiko> being able to easily find these bugs when we have an occurrence?
[18:13] <Rinchen> hmm, there are 73 tagged with test-system today
[18:13] <kiko> that's the main use case
[18:13] <kiko> I'm not strongly +1 but I think it would help to tie this to a process (search using this URL, and research+file if not, email list,
[18:13] <Rinchen> so for these they would have 3 tags
[18:13] <kiko> etc)
[18:14] <Rinchen> infrastructure, test-system, and spurious-test-failure
[18:14] <Rinchen> BjornT, matsubara - your input?
[18:15] <thumper> Rinchen: a spuriour-test-failure might have nothing to do with infrastructure
[18:15] <kiko> right
[18:15] <BjornT> Rinchen: i don't think they would automatically have three tags. just because it's a spurious test failure, it doesn't mean that it's infrastructure
[18:15] <kiko> infrastructure is a pretty useless tag tbh
[18:15] <Rinchen> thumper, indeed but currently all test-system related failures are tagged with both
[18:15] <Rinchen> kiko, yeah, I have to agree on that
[18:15] <flacoste> yeah, not everything is our fault
[18:15] <Rinchen> kiko, It's rare that something is only tagged as infrastructure
[18:15] <kiko> flacoste, now I did NOT say that :)
[18:15] <stub> Just your responsibility :-)
[18:16] <matsubara> the infrastructure tag is from a time before the foundations team
[18:16] <kiko> I'm +1 for retiring that silly tag
[18:16] <flacoste> and change it to foundations?
[18:16] <kiko> and not have a tag
[18:16] <kiko> unless you see a purpose in tagging it that way?
[18:17] <Rinchen> I think the infrastructure tag is too general to serve any purpose these days so +1
[18:17] <matsubara> -1 in retiring tags unless we have mass tag change in launchpad
[18:17] <flacoste> yeah, it means that there is some infrastructure design involved
[18:17] <Rinchen> we'll have to modify 173 bugs though
[18:17] <kiko> UPDATE bugtags ...
[18:17] <BjornT> Rinchen: still, if a bug has spurious-test-failure, it's not necessarily to to with testing infrastructure, so test-system might not be valid there
[18:18] <kiko> agreed
[18:18] <Rinchen> I see no overwhelming disapproval to the spurious-test-failure failure so
[18:18] <flacoste> sold
[18:18] <Rinchen> [AGREED] spurious-test-failure tag approved. Kiko to update the tagging bug page
[18:18] <MootBot> AGREED received:  spurious-test-failure tag approved. Kiko to update the tagging bug page
[18:19] <Rinchen> is there a consensus on retiring infrastructure?
[18:19] <Rinchen> anyone against it?
[18:19] <Rinchen> and who will update those 173 bugs
[18:19] <kiko> does it serve /any/ use?
[18:19]  * Rinchen looks at kiko.
[18:19]  * SteveA belatedly says "me"
[18:19] <Rinchen> https://bugs.edge.launchpad.net/launchpad/+bug/145746
[18:19] <ubotu> Launchpad bug 145746 in launchpad "Upgrade to zope 3.3.1" [High,Triaged]
[18:20]  * thumper looks at SteveA agreeing to update 173 bugs
[18:20] <Rinchen> there are some valid uses for Francis perhaps
[18:20] <kiko> yes, let's not kill him today
[18:20] <kiko> that tag, OTOH
[18:20] <Rinchen> flacoste, what's your opinion since this is in your area
[18:20] <BjornT> do have to remove the tag, just because we retire it? why not just let it fade way?
[18:20] <kiko> we can also let it fade away
[18:20] <kiko> I just don't see any use in advertising it
[18:20] <Rinchen> yes, what kiko said
[18:21] <Rinchen> anyone against this?
[18:21] <flacoste> Rinchen: hmm
[18:21] <Rinchen> flacoste, matsubara ?
[18:21] <flacoste> i think i am against
[18:21] <flacoste> yeah, i think it does has a purpose
[18:21] <flacoste> it collects information on infrastructure need we have
[18:21] <kiko> when have you used it?
[18:22] <Rinchen> the zope item above
[18:22] <flacoste> in planning before 2.0
[18:22] <Rinchen> it's one of the few bugs I see that are infrastructure only
[18:22]  * kiko shrugs
[18:22] <matsubara> I find it useful, specially to address things that should be foundations responsability :-)
[18:22] <flacoste> Rinchen: infrastructure to me means any library-level stuff we need, not necessarily external infrastructure
[18:22] <kiko> ok, never mind then
[18:22] <Rinchen> matsubara, isn't that the ENTIRE launchpad product? ;-)
[18:23] <flacoste> matsubara: kiko's view is what Rinchen just said
[18:23] <Rinchen> [AGREED] we will not retire the infrastructure tag just yet.
[18:23] <MootBot> AGREED received:  we will not retire the infrastructure tag just yet.
[18:23] <Rinchen> ok, the OTHER bug tag
[18:23] <flacoste> but not everything in the launchpad product infrastructure though
[18:23] <kiko> so much controversy!!!
[18:23] <Rinchen> mpt would like to retire the UI tag
[18:23] <flacoste> so the need for the tag
[18:23] <flacoste> i'm -1 on that
[18:23] <kiko> why?
[18:23] <thumper> how should we tag ui bugs then?
[18:23] <mpt> The "ui" tag was defined as "A bug that suggests the user interface is confusing or otherwise difficult to use"
[18:24] <BjornT> looking at the bugs currently tagged with infrastructure, i'd say most of them shouldn't have that tag
[18:24] <flacoste> right
[18:24] <mpt> But for whatever reason, people haven't used it that way
[18:24] <matsubara> yeah, -1 on that unless we can come up with other tags to replace it
[18:24] <flacoste> mpt: given that sense, it's not useful
[18:24] <kiko> flacoste, so you want to keep that tag? fine -- clean up your bugs :)
[18:24] <mpt> They've used it to refer to any bug that touches the UI
[18:24] <flacoste> mpt: right
[18:24] <mpt> which is about 1/2 of them :-)
[18:24] <kiko> mpt, right. so why not add a new one called confusing-interface
[18:24] <kiko> or something like that?
[18:24] <thumper> mpt: I tend to use it to refer to bugs that are purely ui related
[18:24]  * flacoste too
[18:24]  * Rinchen three
[18:24] <mpt> The other reason is that I don't think anyone actually uses it.
[18:25]  * thumper uses it
[18:25] <matsubara> I don
[18:25] <matsubara> I do
[18:25] <matsubara> well, I tag those
[18:25] <mpt> I don't mean uses it as in adds it
[18:25] <mpt> I mean actually uses it as in filters on it.
[18:25] <matsubara> but they'd be more useful when bug #176437, is fixed
[18:25] <ubotu> Launchpad bug 176437 in malone "Conditional searching with tags" [Undecided,New] https://launchpad.net/bugs/176437
[18:25] <Rinchen> I actually use it when I look at your workload mpt :-)
[18:25] <mpt> And I don't think that would change even if we changed its meaning.
[18:26] <Rinchen> it is nice to have a list of all UI based issues
[18:26] <mpt> Rinchen, many of the bugs tagged with UI are bugs I can't fix
[18:26] <Rinchen> that is true
[18:26] <Rinchen> many of those require help from Foundations
[18:26] <thumper> I like the idea of a confusing-user-interface tag (confusing-interface could refer to zope)
[18:26] <kiko> thumper, :)
[18:27] <mpt> I don't think it's useful to have a tag that could be applied to ~1/2 of all bug reports.
[18:27] <thumper> lol
[18:27] <abentley> thumper: Wouldn't confusing-framework refer to Zope?
[18:27] <Rinchen> I admit I would rather have a tag for accessibility/usability issues rather than a generic UI tag
[18:27] <Rinchen> I don't care if something is confusing or not, really.
[18:28] <mpt> Who would use (as in filter on) a tag for accessibility/usability issues?
[18:28] <Rinchen> we could use it to further identify bugs that needed to be addressed as part of the usability study for example
[18:28] <Rinchen> I would very much like to address those findings
[18:28] <thumper> I don't think that the sole use for a tag is to filter on them
[18:29] <mpt> They're listed on the wiki page
[18:29] <thumper> I look at the tags of a bug without filtering on them
[18:29] <mpt> and I think one or two of them have been fixed
[18:29] <mpt> I remind people of them in each State of Launchpad Usability report, but I'm not sure a tag would help
[18:29] <Rinchen> just my personal preference. I'm not attached to it either way
[18:30] <Rinchen> So thumper, matsubara, flacoste  - you expressed concern retiring UI
[18:30] <thumper> if we are going to retire ui, I'd like a tag to refer to UI only bugs
[18:30] <Rinchen> or we could simply amend the UI tag's description
[18:30] <kiko> -1 on retiring, based on this discussion, and +1 for confusing-ui
[18:30] <thumper> as in bugs that can be fixed with browser/template code only
[18:31] <kiko> +1 for amending the description of the ui
[18:31] <mpt> thumper, what counts as "UI only"? Template only? Template + browser code only? Template + browser + interface code only?
[18:31] <flacoste> template+browser
[18:31] <thumper> mpt: that's the discression of the bug triager
[18:32] <Rinchen> flacoste, thumper, matsubara -  looking for +1 or -1 on the proposals from you
[18:32] <flacoste> flacoste: like kiko said
[18:32] <flacoste> Rinchen: ^^^
[18:32] <thumper> -1 on retiring ui, +1 on ammending description of it
[18:32] <matsubara> Rinchen: <matsubara> yeah, -1 on that unless we can come up with other tags to replace it
[18:32] <thumper> +1 on confusing-ui
[18:32] <Rinchen> ok, then
[18:33] <thumper> mpt: less than half our team bugs are confusing-ui
[18:33] <Rinchen> [AGREED] will not retire the UI tag but amend it's description
[18:33] <MootBot> AGREED received:  will not retire the UI tag but amend it's description
[18:33] <Rinchen> [AGREED] create a new tag called confusing-ui to take the place of the original intent of the UI tag
[18:33] <MootBot> AGREED received:  create a new tag called confusing-ui to take the place of the original intent of the UI tag
[18:33] <Rinchen> mpt, would you be so kind as to make those changes to the bug triage wiki page?
[18:34] <mpt> What should the new definition of "ui" be?
[18:34] <kiko> bugs with an ugly face
[18:34] <mpt> ok
[18:35] <Rinchen> mpt, be creative.
[18:35] <Rinchen> thank you mpt
[18:35] <Rinchen> [TOPIC] Operations report (mthaddon/herb)
[18:35] <MootBot> New Topic:  Operations report (mthaddon/herb)
[18:35] <herb> 3/24 - Librarian restarted due to memory usage causing swapping on mizuho
[18:35] <herb> 3/25 - Codebrowse restarted due to memory usage causing swapping on vostok
[18:35] <herb> 3/26 - Codebrowse restarted due to process using 84% of system memory.
[18:35] <herb> Staging will be updated after the items that are currently in the queue.
[18:35] <herb> Production update targeted for 00:00 UTC.
[18:36] <Rinchen> herb, mthaddon - please don't forget to update the news blogs maint page.  I tweaked it yesterday but please ensure it's the right time.
[18:36] <herb> that's it from Tom and I unless there are questions.
[18:36] <Rinchen> herb, if you need access to it, ping me after the meeting.
[18:36] <herb> Rinchen: will do
[18:36] <Rinchen> thanks
[18:36] <Rinchen> kiko, what's the story with the librarian leak?
[18:36] <Rinchen> kiko, I know you were looking into that with spiv
[18:37] <kiko> Rinchen, we are stumped. mthaddon patched the librarian and re-ran it and no change. :-(
[18:37] <Rinchen> fooey
[18:37] <mpt> wiki updated.
[18:37] <kiko> Rinchen, I don't have the cycles to chase this myself but can help somebody who can
[18:37] <Rinchen> wonder if we can setup an instance locally and valgrind it
[18:37] <kiko> i.e. flacoste who loves libby
[18:37] <kiko> it's not a valgrind issue
[18:37] <kiko> that's a crazy suggestion
[18:37] <Rinchen> I'm a crazy guy :-)
[18:38] <kiko> it's just a matter of doing some python investigation
[18:38] <Rinchen> mpt thanks
[18:38] <kiko> flacoste <3 libby
[18:38] <kiko> ...
[18:38] <flacoste> kiko: yeah, i could it a shot
[18:38] <Rinchen> right then, thanks
[18:38] <kiko> flacoste, do you know the history behind this?
[18:38] <flacoste> kiko: vaguely, we can discuss this later
[18:38] <kiko> yes, please call me
[18:39] <Rinchen> [ACTION] flacoste to take a stab at the librarian issues next week
[18:39] <MootBot> ACTION received:  flacoste to take a stab at the librarian issues next week
[18:39] <Rinchen> thanks flacoste
[18:39] <flacoste> kiko, i'll call you tomorrow
[18:39] <Rinchen> [TOPIC] DBA report (stub)
[18:39] <MootBot> New Topic:  DBA report (stub)
[18:39] <stub> Nothing to report.
[18:39] <kiko> sure thing
[18:39] <Rinchen> 2nd week in a row there stub
[18:39] <Rinchen> Anything for stub?
[18:39] <kiko> stub, what's going on with the PAS stuff?
[18:40] <stub> Should be thankfull - we are getting to overtime :-)
[18:40] <kiko> person-auth-split IYDKWIM
[18:40] <stub> Jamesh threw some spammers into the works so I've got three designs now.
[18:40] <kiko> wow, really?
[18:41] <stub> Stuff that needs to be in the auth database and the lp database
[18:41] <kiko> grumble
[18:41] <kiko> stub, what's the next step?
[18:42] <stub> Think hard about them, write opinions for and against and get feedback.
[18:42] <kiko> stub, you want to schedule that?
[18:42] <stub> I've got the spec scheduled for this next cycle
[18:42] <stub> erm... 1.2.4
[18:43] <kiko> stub, meaning just the spec, or impl starting too?
[18:43] <stub> Hopefully both.
[18:43] <kiko> okay, good. let's catch up again next week, week zero!
[18:43] <stub> Just stop throwing spanners at me
[18:43] <Rinchen> thanks stub
[18:43] <Rinchen> [TOPIC] Sysadmin requests (Rinchen)
[18:43] <MootBot> New Topic:  Sysadmin requests (Rinchen)
[18:43] <kiko> the spammers are throwing themselves at us :-/
[18:43] <kiko> (Rinchen, do we need to remind people that we are in "ubuntu freeze"?)
[18:43] <Rinchen> Hi! Is anyone blocked on an RT or have any that are becoming urgent? I'm tracking 1 overdue for Julian, 1 overdue for me, 1 for IS (apache), and 1 for kiko.  The IS one is the only one making any progress.
[18:44] <kiko> the security apache thingy is important
[18:44] <bigjools> kiko asked me to mention the one for mail capture on dogfood
[18:44] <Rinchen> that's the one I have :-)
[18:45] <bigjools> cool
[18:45] <Rinchen> So I apologize that I've not been able to move these others along.
[18:45] <Rinchen> Scheduling with IS has been difficult lately
[18:45] <kiko> it's release month, understandable
[18:45] <Rinchen> as always, lots of stuff on their plate
[18:45] <Rinchen> indeed
[18:46] <Rinchen> kiko,  I wasn't going to remind folks about stable... I think everyone knows.  It doesn't seem to make much difference anyway since you, me, and Steve approve cherries
[18:46] <Rinchen> and we know
[18:46] <Rinchen> [TOPIC] New packages required (salgado)
[18:46] <MootBot> New Topic:  New packages required (salgado)
[18:46] <SteveA> hold your horses, we're in stable
[18:46] <kiko> Rinchen, it's not just cherry-picks
[18:47] <kiko> it's also edge landings.
[18:47] <salgado> if any of the branches you're working on right now  depends on any library which is not part of the launchpad-dependencies package, come talk to me ASAP.
[18:47] <kiko> be specially careful about what you land
[18:47] <stub> I think pytz should end up in lp-dep
[18:47] <stub> And lost from sourcecode
[18:47] <kiko> because if it annoys ubuntu, it will really annoy me
[18:47] <adeuring> salgado: I will need  the lexml2-utils package soon
[18:47] <kiko> stub, are we no longer updating it?
[18:47] <SteveA> stub: once we move servers to hardy?
[18:47] <salgado> adeuring, you've filed the bug already?
[18:48] <stub> kiko: There is no need to keep it updated if we use the Ubuntu one, as it uses the system libraries
[18:48] <adeuring> salgado: yes
[18:48] <stub> SteveA: sure
[18:48] <salgado> adeuring, can you define soon in the bug?
[18:48] <adeuring> salgado: I'll add a comment
[18:48] <Rinchen> salgado, https://bugs.edge.launchpad.net/launchpad/+bug/81082
[18:48] <ubotu> Launchpad bug 81082 in launchpad-dependencies ""Australia/Perth" time zone needs updating" [Medium,Confirmed]
[18:49] <Rinchen> Anything else for salgado?
[18:49] <Rinchen> no on-time ending for us today
[18:49] <Rinchen> [TOPIC] A top user-affecting issue (mrevell)
[18:49] <MootBot> New Topic:  A top user-affecting issue (mrevell)
[18:49] <mrevell> This week's issue is pertinent to a week in which we're making a release :)
[18:49] <mrevell> Throughout the month, we add new/changed functionality to Edge but we don't announce what the changes are. This prompted a question on launchpad-users a couple of days ago.
[18:49] <mrevell> Edge is clearly marked as a beta environment. However, I wonder if:
[18:50] <mrevell> a) there's an easy way (i.e. largely automated) to show beta testers what's changed over night on Edge
[18:50] <mrevell> b) if that's something we would want to put time into, as we clearly mark Edge as beta and people know that it's a rapidly changing environment.
[18:50] <mrevell> Cheers.
[18:50] <intellectronica> perhaps we could have an edge blog, where we add a couple of words for every new feature that makes it there?
[18:50] <kiko> well
[18:51] <kiko> the way I'd do that is somehow do a daily transport of commits to news
[18:51] <barry> mrevell: what about a feed of the subjects of pqm landings that don't have !log?
[18:51] <Rinchen> we could strip [!log] from arch commits at the moment and just update that daily
[18:51] <kiko> which could then be used as the user-visible part of our release notes later, so it's not waster work.
[18:51] <kiko> Rinchen, barry: not really user-consumable
[18:51] <stub> How many people would genuinely read more information about LP developments?
[18:51] <mrevell> kiko: Yeah, so distribute the release notes work throughout the cycle.
[18:51] <kiko> right
[18:52] <kiko> do it daily -- it's only like 1-5 entries a day anyway
[18:52] <Rinchen> mrevell, we could have a separate blog category about it
[18:52] <Rinchen> mrevell, something that doesn't post to the Planet
[18:52] <mrevell> Yeah. My only concern is vacation time, but I think we can cover that int he usual ways
[18:52] <barry> kiko: yeah, we'd have to be more careful about that
[18:52] <kiko> mrevell, I can cover for you if you like. I sometimes know how to write.
[18:52] <mrevell> Rinchen: Hmm, that might be trickier but I'm sure we could do it.
[18:52] <mrevell> kiko: Heh :) You certainly do.
[18:52] <Rinchen> kiko, it's a lot of work to do it by hand
[18:53] <kiko> Rinchen, it's the same work as mrevell puts into the announcement?
[18:53] <kiko> except spread out
[18:53] <Rinchen> yeah, the scripts don't take long to run
[18:53] <Rinchen> but mrevell has other commitments on week 2
[18:53] <Rinchen> mrevell, have we proposed this on -users or a users meeting?
[18:54] <Rinchen> I agree it's a good thing to do but I'd rather consider it by hand after we dogfood
[18:54] <mrevell> Rinchen: No, not yet. I wanted to float the idea here  first
[18:54] <Rinchen> er
[18:54] <Rinchen> I'd rather not consider doing it mostly by hand
[18:54] <Rinchen> and wait until we dogfood which is coming
[18:54] <mrevell> Cool, let's discuss it further another time.
[18:54]  * Rinchen looks at thumper 
[18:54] <kiko> dogfood?
[18:54] <kiko> huh?
[18:54] <Rinchen> kiko, RF on LP
[18:54] <kiko> Rinchen, the commit messages will not be user-consumable, so that's irrelevant
[18:55] <kiko> there needs to be manual work done
[18:55] <kiko> and we already do the manual work anyway when producing the monthly report
[18:55] <Rinchen> yes, that's true
[18:55] <thumper> Rinchen: it won't make any difference to the uses as the brance will be private
[18:55] <kiko> now
[18:55] <thumper> Rinchen: until we release the source anyway
[18:55] <kiko> it doesn't have to be matt r. that does it
[18:55] <kiko> but that would involve team leads wanting to take that job on
[18:55]  * thumper has typo spelling mistakes when tired
[18:56]  * flacoste makes long-convulated sentences.
[18:56] <Rinchen> hmm, ok.  mrevell, please gauge the community's interest in this.
[18:56] <flacoste> with lots of made-up words!
[18:56] <mrevell> Rinchen: Will do.
[18:56] <stub> I think it would be good if we could determine who our audience is for these missives.
[18:56] <Rinchen> if there is enough then I'll move forward with this with you
[18:56] <SteveA> there is a benefit to us
[18:56] <SteveA> which is, beta testers can be directed at things that have changed
[18:57] <SteveA> to check them out, if they feel minded to do so
[18:57] <Rinchen> and this then draws attention to new items which would get good qa
[18:57] <thumper> mrevell: what about the announcements on the launchpad product for this?
[18:57] <kiko> yeah, I think the same as SteveA
[18:57] <Rinchen> thumper, I was thinking about that too as an avenue
[18:58] <mrevell> thumper: Yeah, that's a good idea. So long as it was clearly marked as affecting edge
[18:58] <Rinchen> I can digest a weekly effort but I'm having a difficult time with a daily one by hand given the large amount of workload mrevell has.
[18:58] <Rinchen> anyway, I'm calling time and moving on
[18:58] <Rinchen> [TOPIC] Doc Team report (mrevell)
[18:58] <MootBot> New Topic:  Doc Team report (mrevell)
[18:59] <mrevell> Hey - not much to report in DocsWorld this week, while I've been working on the release announcements etc. I've prepared some documentation updates ready for the release and some blog posts that'll go live tomorrow, again for the release.
[18:59] <Rinchen> thanks
[18:59] <mrevell> Thanks again to people who've provided feedback on docs posted to the list.
[18:59] <mrevell> Cheers
[18:59] <Rinchen> [TOPIC] What environments use zopeless mode and require send_email: true (sinzui)
[18:59] <MootBot> New Topic:  What environments use zopeless mode and require send_email: true (sinzui)
[18:59]  * thumper doesn't like the term zopeless
[18:59] <kiko> agreed
[19:00] <kiko> but anyway
[19:00] <thumper> bazaar-staging needs to send email
[19:00] <sinzui> My question might be better stated is that I think we have cargo-culted the value to True in many places.
[19:00] <kiko> curtis and I yesterday put a best effort into figuring out what instances and processes needed email disabled
[19:00] <sinzui> thumper: noted
[19:00] <kiko> meaning that zopeless processes using that config should be stopped from sending email
[19:01] <SteveA> can we not just log if something sends email
[19:01] <kiko> sinzui, remind us what we decided to go with?
[19:01] <SteveA> then inspect the logs
[19:01] <SteveA> st jude style
[19:01] <kiko> SteveA, no clue, but there's no time for that
[19:01] <kiko> it could have been done weeks ago, but not 5h before the rollout!
[19:01] <sinzui> We have enabled send_email to true in all environments (per the old confs) except for default, testrunner, bazaar-staging, and ...
[19:02] <stub> process-email should be it on forster, shouldn't it?
[19:02] <sinzui> dogfood
[19:02] <kiko> default meaning devel for clueless people like me. testrunner inherits it.
[19:02] <stub> Maybe the probers to annoy mirror owners?
[19:02] <kiko> bazaar-staging and dogfood had it disabled as well, though there is an argument that we should instead configure those boxes to redirect smtp traffic.
[19:02] <sinzui> kiko: right. there is nothing default about default.
[19:03] <kiko> :)
[19:03] <Rinchen> thumper, shouldn't bazaar-staging go to the staging mailbox?
[19:03] <kiko> Rinchen, it's not the same server.
[19:03] <thumper> Rinchen: yes, probably
[19:03] <stub> oh - rosetta imports and maybe exports spam users
[19:03] <kiko> thumper, if you agree, please file an RT ticket and give the number to Rinchen
[19:03] <thumper> can it?
[19:03] <kiko> so, if you know of a place where we should NOT send email from zopeless scripts please warn us.
[19:04] <flacoste> thumper: if bazaar-staging is running on staging, it already does
[19:04] <sinzui> What environment is rosseta imports?
[19:04] <kiko> flacoste, it doesn't.
[19:04] <kiko> stub, well, where would those be at risk?
[19:04] <kiko> what I mean is, on what instance would rosetta imports or the mirror prober run where we would /not/ want to send out email?
[19:04] <flacoste> then bazaar-staging should have send_email False for now
[19:04] <stub> sinzui: zopeless scripts run from cron
[19:04] <kiko> staging, yes, but staging has an auto-smtp-redirect.
[19:04] <kiko> flacoste, that's the way it is.
[19:05] <kiko> stub, see my statement above.
[19:05] <stub> kiko: I think there is already a command line option to the mirror prober to send out or not send out email
[19:05] <flacoste> kiko: i know, but thumper asked sinzui to change that
[19:05] <sinzui> stub: but what conf file? if it is run on forester, I assume production,
[19:05] <kiko> flacoste, I think he didn't -- he just didn't understand it was staging at that point :)
[19:05] <stub> kiko: I can't think of any cases where we need to disable rosettas email without needing to disable the imports entirely
[19:05] <stub> sinzui: Yes (Tom?)
[19:06] <kiko> stub, agreed -- except on staging, during testing, where as I said, it's irrelevant.
[19:06] <thumper> I kind of assumed that the email sent from bazaar-staging would go to the staging email box
[19:06] <kiko> thumper, it's not on the same server
[19:06] <thumper> if it takes a while to set that up, then we should set it to False for now
[19:06] <kiko> so it won't
[19:06] <kiko> right
[19:06] <kiko> anyone else?
[19:06] <thumper> kiko: yeah, but I didn't know that it wouldn't work
[19:06] <kiko> thumper, well, there's no magic -- special smtp config needs to be done. :)
[19:06]  * flacoste sees that notifications from bazaar-staging were tested properly...
[19:07] <Rinchen> [TOPIC] LaunchpadValidationError and HTML escaping (intellectronica, kiko)
[19:07] <MootBot> New Topic:  LaunchpadValidationError and HTML escaping (intellectronica, kiko)
[19:07] <kiko> sinzui, looks good to me -- and I replied to your email about the key discrepancies, pointing out ones I found suspicious. nothing there is critical IMO.
[19:07] <kiko> okay
[19:07] <sinzui> kiko: thanks. I'll loook at my mail
[19:08] <kiko> what do people think about doing escape of LVE strings to avoid callsites needing to remember to do it?
[19:08] <kiko> we could do something similar to what mars did
[19:08] <kiko> for our web notifs
[19:08] <kiko> i.e. supply structured where desired, otherwise, escape
[19:08] <kiko> what think you?
[19:08] <stub> I liked that pattern
[19:08] <flacoste> +1
[19:08] <intellectronica> that, of course, means not escaping when the input is wrapped in structured, and going over all existing places and converting them, since some of them feed HTML in
[19:08] <barry> +1, with structured
[19:09] <intellectronica> +1
[19:09] <kiko> I'm +1 too
[19:09] <kiko> okay thanks
[19:09] <kiko> please keep in mind this is currently an issue
[19:09] <SteveA> I don't care about seeing some spurious < and > in the HTML for a while
[19:09] <kiko> right
[19:09] <SteveA> that's a small usability problem we can progressively fix
[19:09] <intellectronica> and many should be caught by tests anyway
[19:09] <kiko> flacoste, mars: can you guys file a bug?
[19:09] <SteveA> so, add escaping now :)
[19:09] <kiko> yeah, totally
[19:09] <SteveA> thanks for bringing this up
[19:10] <mars> kiko, sure
[19:10] <kiko> thanks
[19:10] <Rinchen> [AGREED] we should try to avoid callsites by escaping LVE strings - supply structured where desired, otherwise, escape
[19:10] <MootBot> AGREED received:  we should try to avoid callsites by escaping LVE strings - supply structured where desired, otherwise, escape
[19:10] <Rinchen> [TOPIC] Blockers
[19:10] <MootBot> New Topic:  Blockers
[19:10] <Rinchen> Releases Team: Not blocked.
[19:10] <thumper> Code: not blocked
[19:10] <BjornT> Bugs: not blocked
[19:10] <bigjools> Soyuz: blocked on RT as discussed
[19:11] <flacoste> Foundations: not blocked
[19:11] <jtv> Translations: not blocked
[19:11] <kiko> flacoste, well, sinzui depends on answers to that email.
[19:11] <Rinchen> EdwinGrubbs, bigjools, SteveA ?
[19:11] <kiko> so kinda blockeraged
[19:11] <bigjools> Rinchen: ?
[19:11] <Rinchen> ah sorry
[19:11] <Rinchen> I'm blind
[19:11] <kiko> bigjools, Rinchen fat-fingered it
[19:11] <flacoste> kiko: internal blockage doesn't count :-)
[19:11] <adeuring> hwdb: not blocked (exception: the lxml review...)
[19:11] <flacoste> kiko: and i'm replying now
[19:11] <bigjools> flacoste: ewww
[19:11] <EdwinGrubbs> LPComm: blocked on staging to test revision 5968 and staging is waiting on pqm to finish
[19:12] <kiko> adeuring, yeah, you get on a reviewer and make him UNDERSTAND THE THREAT :)
[19:12] <Rinchen> (the threat being kiko)
[19:12] <Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
[19:12] <Rinchen> #endmeeting
[19:12] <MootBot> Meeting finished at 20:13.
[19:12] <mrevell> thanks all!
[19:12] <mpt> Marathon!
[19:12] <Rinchen> indeed
[19:12] <intellectronica> thanks Rinchen
[19:12] <mpt> thanks Rinchen
[19:12] <intellectronica> today we got 66% extra!
[19:12] <Rinchen> for free!
[19:13] <kiko> intellectronica, for the same price too
[19:13] <kiko> amazing
[19:13] <kiko> these americans really know how to market stuff
[19:13]  * bigjools now rushes off to put the kids to bed