[12:08] <spiv> mdke: pong
[12:09] <mdke> spiv, oh great, hi.
[12:10] <mdke> spiv, we would like to get hold of a list of email addresses of users who have accounts on the wiki. how hard is that going to be?
[12:10] <spiv> As in, a list of email addresses of users that have ever logged in to the wiki?
[12:11] <mdke> spiv, well ideally, those who have ever edited the wiki, but I think we'd settle for logged in
[12:11] <spiv> Hmm.
[12:11] <mdke> in normal moin i guess it wouldn't be very hard
[12:12] <mdke> but i don't know what the user database looks like on our moin
[12:12] <spiv> Well, the changes to our moin aren't that big.
[12:12] <spiv> It's basically a two-step process:
[12:12] <mdke> so some kind of search script for /data/user/* would do the trick?
[12:13] <spiv>   1) extract a list of user IDs from the moin files
[12:13] <spiv>   2) query the launchpad database for the email addresses for those users
[12:13] <mdke> ok, so maybe not too bad?
[12:14] <spiv> For step 1, you could even trawl through the history of all edits to narrow it down to people that have edited the wiki, but that's more work than just grabbing the id of every user file :)
[12:14] <mdke> yeah the id way works for me
[12:15] <mdke> spiv, do you have any idea how long something like that would take to write for one of you super geek guys?
[12:15] <spiv> We'll need an admin to do step 1, I don't have access to the wiki data files (although I can help by writing a script for them to run)
[12:16] <mdke> the admin thing shouldn't be a problem
[12:16] <mdke> it's just a question of getting the script written
[12:16] <spiv> Not very long, let me remind myself what the data files look like :)
[12:25] <mdke_> spiv, sorry, may have missed anything you said since "remind myself what the data files look like", got disconnected
[12:25] <spiv> mdke_: You didn't miss anything.
[12:25] <mdke_> ah cool
[12:25] <spiv> The script for the admins to run is easy, though: "ls 
[12:25] <spiv> bah,
[12:26] <spiv> "ls $moin_user_dir" :)
[12:26] <spiv> mdke: Do you just need this as a once-off?
[12:27] <mdke> yup
[12:27] <mdke> we can work out the exact details with elmo another time
[12:27] <mdke> i just wanted to find out how hard/easy it would be
[12:29] <mdke> spiv, is stage (2) quite easy too?
[12:29] <spiv> mdke: Yeah, just a simple matter of SQL.
[12:30] <mdke> :)
[12:30] <mdke> spiv, ok great, thanks for your time
[01:15] <doko> bradb: ping
[01:15] <bradb> doko: hi
[01:16] <doko> sorry, I strongly disagree on #3882
[01:17] <bradb> doko: Why?
[01:17] <doko> the whole distro team does work this way: work on one aspect on one package, and then go on to the next one. If I have to subscribe to each package I apply a fix ... that's just administration effort
[01:18] <bradb> doko: You don't have this feature in Bugzilla, AIUI, right?
[01:18] <doko> bugzilla is not the measure
[01:20] <doko> if I look at debian, they some kind of this feature implemented. it's not just a malone thing. it's about tracking of an upload you make, and taking responsibilty about it. currently I have to poll many different sources for this information:
[01:21] <bradb> doko: I'm not saying your suggestion is a bad one, only that you're the only person I've heard ask for it and, IMHO, it would add more complexity than benefit.
[01:21] <doko> people.ubuntu.com/~lamont/buildLogs, bugzilla/malone, anastacia output, colin's dapper-probs, etc ...
[01:22] <bradb> doko: How would Malone know when to subscribe you? Can it make these kinds of assumptions for every upload done to Malone? How would it know when to unsubscribe you?
[01:23] <doko> bradb: because everybody just polls this information, which seems to be a ridicoulous waste of resources. 
[01:24] <bradb> doko: Okay, let's walk through this. First question: how would Malone know when to subscribe you to all bugmail for a package?
[01:24] <lifeless> SteveA: ping
[01:24] <doko> bradb: launchpad should know about the uploader field, so that is the information you need. for unsubscription: either unsubscribe when somebody else uploads the package, or terminate the subscribte after some fixed time
[01:24] <doko> bradb: subscribe: when somebody makes an upload
[01:25] <bradb> doko: Would that assumption be a helpful one for the majority of cases?
[01:26] <doko> where upload is: upload signed by this person (which probably will not cover sponsored uploads, I'll have to check this)
[01:26] <lifeless> spiv: ping
[01:27] <doko> bradb: yes, manual uploads are usually signed by the people who work on the packages. exceptions are syncs from unstable and sponsored packages
[01:28] <bradb> doko: Okay, so will most developers want to start getting bugmail from packages at the moment they do an upload of that package?
[01:29] <doko> we surely can formalize syncs from unstable. for sponsored uploads, we could maybe subscribe the sponsor (uploader) and the person in the changelog
[01:30] <doko> bradb: yes, I think that would be helpful. that would elminate the work done by a bug master (currently mdz) assigning bugs to members of the distro team
[01:31] <doko> bugs are one aspect, but this kind of sbscription feature should cover all other information related to a package
[01:31] <bradb> doko: And will it be the most helpful option to have Malone unsubscribe developers as pkg bug contacts automatically when someone else does an upload of their package?
[01:32] <bradb> s/their/the/
[01:33] <doko> bradb: that's one point to discuss. I'm not sure about it. I surely do not want to last the subscription forever. therefore the proposal to terminate the subscription after some time, or terminate it after the next upload done by another person
[01:34] <bradb> doko: What if the person were actually a pkg bug contact by choice as well?
[01:34] <doko> then the point of contact has priority
[01:34] <bradb> This is the kind of complexity to which I'm referring?
[01:35] <bradb> er, s/\?/:)/
[01:36] <bradb> From this other questions fall out about the complexity: can a user turn this off? If so, how? How do we communicate clearly to the developer why they suddenly started getting bugmail, and also somehow let them know that it won't continue forever, and don't-worry-we'll-auto-unsubscribe-you-soon-enough, etc?
[01:36] <doko> I know ... please see it from my side. currently I have to poll several sources of information for each package I touch. a) that's work which can be automated b) if I forget/make mistakes, nobody will notice (at least for some time)
[01:36] <doko> s/user/developer/
[01:37] <bradb> doko: I agree fully with you that wasting your time is bad.
[01:37] <spiv> lifeless: pong
[01:37] <lifeless> this may be more effective if a spec with use cases is worked through
[01:37] <lifeless> that will make clear whats involved, and let other folk put in feedback, whereas IRC conversation is markedly opaque
[01:37] <lifeless> spiv: yoyoyo
[01:37] <lifeless> spiv: in DB interfaces
[01:38] <lifeless> are related things like 'owner' normally presented as the object or as the underlying db type.
[01:38] <lifeless> i.e. in IFoo
[01:38] <doko> lifeless: agreed, but IMO there are use cases in the report. I'm just happy about the status change for needinfo->rejected
[01:38] <lifeless> if there is an 'owner', and I have something implementing IFoo, would we expect thing.owner to be an 'int' or a 'IPerson'
[01:38] <spiv> lifeless: The object.  So 'owner' would typically be something providing IPerson, for instance.
[01:39] <lifeless> +    owner = Int(
[01:39] <lifeless> > +        title=_('Owner'), required=True, readonly=True)
[01:39] <lifeless> so that looks wrong to you?
[01:39] <spiv> Yep
[01:39] <spiv> Should be a ForeignKey.
[01:39] <lifeless> yay
[01:39] <doko> bradb: I agree that it would be not a minor change to malone/launchpad. should we make this discussion on a mailing list as well?
[01:39] <spiv> Oh, interface.
[01:39] <spiv> But yeah, not Int :)
[01:40] <bradb> doko: Sure.
[01:40] <bradb> doko: Do you want me to forward the information somewhere, and where would you prefer to have the discussion take place? (I'm not sub'd on any Ubuntu lists, FWIW.)
[01:42] <doko> bradb: I think ubuntu-devel would be appropriate, let's prepare that mail, it's not that urgent. start of January should be fine
[01:42] <spiv> lifeless: Look at IBugSubscription, for instance
[01:42] <lifeless> spiv: its ok
[01:42] <lifeless> spiv: I needed to check the expected state, not the 'occuring state'
[01:42] <bradb> doko: Can non-subs post to that list?
[01:42] <lifeless> spiv: which is why the source wasn't good enough ;)
[01:43] <lifeless> spiv: thanks !
[01:43] <doko> bradb: if jdub takes care of these post, yes. so better subscribe ;-)
[01:43] <spiv> lifeless: Well, IBugSubscription's person attribute looks like what I expect :)
[01:44] <lifeless> thanks
[01:44] <doko> s/post/posts/
[01:47] <bradb> doko: Hm, I'd rather not subscribe to the list just to get mail about this one thread. I wonder if you'd be happy with this solution: 1. I move the bug report back to "New", 2. You mail ubuntu-devel asking for input on the feature request and Cc me. Is that reasonable?
[01:47] <lifeless> spiv: IBugSubscription exposes the bug number rather than the bug.
[01:47] <lifeless> spiv: that seems wrong to me.
[01:48] <lifeless> spiv: going off what we just discussed
[01:48] <lifeless> spiv: while I have your attention, is exposing the 'id' de rigeur ?
[01:48] <doko> bradb: ok. I'll prepare an email. let us polish that email until we agree on the points we disagree
[01:50] <spiv> lifeless: Hmm, there is a BugVocabulary, but it appears to be unused.  I wonder why.
[01:50] <bradb> doko: Sure. BTW, it's not that I "disagree" with your time being important and that Malone should help reduce your development burden as much as possible, only that adding this feature would add a lot more complexity than benefit for most users, IMHO. But, I look forward to enlightenment from your email. ;)
[01:51] <spiv> (I guess because Int works well enough...)
[01:52] <lifeless> spiv: well it applies force on IBug to show the db id
[01:52] <lifeless> spiv: as we are punning the number and db id
[01:52] <lifeless> spiv: anyway, is showing the 'id' usual ?
[01:53] <lifeless> or is it explicitly thought through each time ?
[01:53] <spiv> lifeless: To be honest, I'm not sure.
[01:54] <lifeless> ok
[01:54] <spiv> And a quick survey of the existing code gives inconsistent results ;0
[01:54] <bradb> doko: I marked the bug as "New" again, btw. Thanks for your feedback, and I'm looking forward to hearing what u-d says about it.
[01:55] <spiv> bradb: mailman allows you to "subscribe", but mark your subscription as "no mail".
[01:55] <bradb> spiv: Indeed. How would that help here?
[01:55] <spiv> bradb: So you can post unrestricted, without being flooded with mail.
[01:55] <bradb> Ah, ok, good point.
[01:57] <bradb> I think doko will do the best job of selling his feature request to u-d.
[01:58] <spiv> Fair enough.
[01:59] <bradb> lifeless: BTW, my code has spent all day in the #1 spot in pqm by now. It seems like the 40 min estimate earlier may have been optimistic.
[02:00] <bradb> Er, "upwards of 40 minutes or more", but that was two and a half hours ago. :)
[02:00] <lifeless> bradb: I said upwards for a reason
[02:01] <lifeless> bradb: this is what sftp push in bzr does at the moment
[02:01] <lifeless> bradb: its extremely inefficient
[02:03] <bradb> right
[02:04] <bradb> FWIW, I hate whining about pqm and I'm mostly surely a pest about it, but I dislike even more not being able to do my job.
[02:09] <lifeless> right
[02:09] <lifeless> so right now, how is it blocking you ?
[02:14] <bradb> lifeless: I need to get at the most recent code in Launchpad to fix the tests and conflicts in my bug status changes branch. I could do a sideways merge, but you said earlier that I can't necessarily trust that.
[02:14] <lifeless> bradb: I suggested you do one
[02:15] <lifeless> bradb: the trust is whether pqm succeeds in its push or not
[02:17] <bradb> Ok, I'll do one tomorrow if for some reason I still don't have access to that revision in my usually rsync launchpad-upstream => local merge workflow.
[02:19] <bradb> It's all literally blocking me in the sense that if I'd done that and submitted it immediately after seeing that all the tests pass, it'd still be #3 in pqm's queue right now. This two patches I'm getting through right now are kind of particularly critical to land before causing painful conflicts in almost any other Malone changes.
[02:19] <lifeless> unfortunately I cannot make it faster
[02:19] <lifeless> this is where the tech is at at this point
[02:19] <lifeless> the bzr group are working very hard to get improvements in place.
[02:21] <jamesh> bradb: I'll update my bugzilla default assignees migration script to work with the initial-bug-contacts stuff
[02:22] <bradb> jamesh: Ok, great, thanks.
[02:26] <jblack> Did you guys see http://geekz.co.uk/lovesraymond/archive/clique? 
[03:36] <eruin> shuttleworth foundation empire
[03:36] <eruin> ;)
[06:30] <jblack> jamesh: ping
[06:30] <jamesh> jblack: pong
[06:30] <jblack> I think your http://people.ubuntu.com/~jamesh/bzr.smallfixes  branch may be borked
[06:30] <jamesh> jblack: oh?
[06:31] <jblack> bzrlib.errors.MissingText: Branch http://people.ubuntu.com/~jamesh/bzr.smallfixes is missing revision robertc@robertcollins.net-20050919060519-f582f62146b0b458 of cacheremoterevisions.diff-20050615041652-ec41056afda8ec11
[06:31] <jamesh> that's unfortunate
[06:31] <jblack> ohhh....
[06:31] <jblack> orrr..
[06:31] <jblack> the supermirror bzr may be too old
[06:31] <jamesh> I don't think there are any unmerged revisions in that branch though
[06:31] <jblack> s
[06:44] <jblack> Nope.
[06:44] <jblack> That won't do it.
[06:44] <jblack> jamesh: Can you branch yourself? 
[06:45] <jamesh> jblack: "bzr branch" seems to work with my local copy of the branch
[06:47] <jamesh> jblack: I'm just pushing the branch again
[06:47] <jamesh> my local copy includes some extra revisions I'd pulled from bzr.dev
[06:49] <jamesh> finished pushing
[06:50] <jblack> thanks
[07:07] <jblack> jamesh: I think you may need to reweave your branch
[07:08] <jblack> Which I can provide instructions for
[09:25] (SteveA/#launchpad) although, there are other forms for multiple men or men and women, and for multiple women
[09:25] (sivang/#launchpad) eh, niec
[09:25] (sivang/#launchpad) *nice
[09:26] (lifeless/#launchpad) thats getting seriously kinky
[09:26] (sivang/#launchpad) lifeless: lol :)
[09:28] <sivang> SteveA: seems that Lithuanian is very specific language
[09:32] <lifeless> SteveA: were you pinging or just wasving ?
[09:43] <SteveA> lifeless: you pinged earlier, when i was asleep
[09:47] <lifeless> mmm, did I
[09:47] <lifeless> oh right
[09:47] <lifeless> style for interfaces. spiv helped me
[10:08] <carlos> morning
[10:08] <sivang> carlos: Hola
[10:08] <carlos> sivang, hola!
[10:27] <SteveA> sivang: for example if you're greeting a group of young women, "sveikos panels!" would be "hello girls!" 
[10:32] <SteveA> i meant, "sveikos panels" means "i smell of donkeys"
[10:36] <lifeless> thats not MY donkey
[10:37] <mdke> that will work on the ladies
[10:38] <SteveA> well, it won't work on *all* the ladies
[10:48] <sivang> SteveA: LOL
[11:45] <stub> jamesh: So you had no luck with that odd foaf pagetest failure?
[11:46] <jamesh> stub: I've added a couple of syncUpdate() calls in places that look like they need it
[11:47] <jamesh> and I can't reproduce it anymore, but that might not mean it is solved
[11:47] <stub> jamesh: Have these landed? We could reproduce consistantly on the PQM box for no apparent reason
[11:48] <stub> jamesh: I was going to attack the problem with pdb thought I better ask in case I was wasting my time
[11:48] <jamesh> stub: no.  They're in my select-results-len-fix branch
[11:48] <stub> ok. I might merge that in and see what happens on balleny
[11:48] <jamesh> stub: search for syncUpdate() for the bits that might be the culprit
[11:49] <jamesh> it might be easier to just pick out the hunks in question
[11:49] <jamesh> there are two hunks which add syncUpdate() calls
[11:51] <tuhl> ping Daniel Silverstone | Steve Alexander
[11:52] <Deepa> can you no longer get free ubuntu CD's?
[11:53] <stub> Deepa: Sure - https://shipit.ubuntu.com
[11:53] <Deepa> oops my mistake :P
[11:53] <Deepa> i was searching around on launchpad.net XD
[12:06] <salgado> stub, around?
[12:07] <stub> yes
[12:07] <salgado> stub, do you have a couple minutes to take a look at my DB patch for mirror management (https://chinstrap.ubuntu.com/~dsilvers/paste/filei41vyp.html)?
[12:09] <matsubara> good morning!
[12:10] <stub> salgado: Should distributionmirror.name have a constraint, or is any old rubbish acceptible as the name?
[12:10] <salgado> stub, it needs the valid_name constraint. I added it in the interface but forgot to add here
[12:11] <stub> Are there comments available?
[12:11] <salgado> not yet, I forgot them again. will write now, though
[12:17] <stub> salgado: What is an rsync_base_url look like?
[12:18] <stub> c/is/does
[12:19] <salgado> stub, I expect it's something like rsync://host.tld/some/path
[12:21] <stub> salgado: Ok. Just wanted to make sure it was really a url and not foo.domain:whatever syntax
[12:21] <stub> speed > 0 ?
[12:21] <stub> salgado: ^^
[12:21] <stub> Or is that a dbschema
[12:21] <salgado> yep
[12:21] <salgado> dbschema
[12:22] <stub> and content dbschema?
[12:22] <salgado> yes
[12:25] <stub> salgado: MirrorProbeRecord has a NULLable date_created? Is that correct?
[12:26] <stub> and no default
[12:26] <salgado> no, it's not. it should default to NOW and be not null. my fault
[12:50] <stub> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filee4kUpc.html
[12:50] <stub> salgado: Approved patch-40-13-0.sql pending addition of good comments
[12:50] <salgado> stub, great. thank you
[12:53] <cprov> morning ...
[01:00] <jblack> tick. tick tock
[01:00] <salgado> it's meeting time!
[01:00] <lifeless> SteveA: new items for the agenda
[01:01] <jblack> I have a hunch I know what
[01:01] <SteveA> thanks lifeless 
[01:01] <SteveA> MEETING TIME
[01:01] <SteveA> who is here today?
[01:01] <jamesh> me
[01:01] <daf> I am
[01:01] <spiv> me
[01:01] <jblack> I am here in body
[01:01] <lifeless> moi
[01:01] <matsubara> me
[01:01] <bradb> me
[01:02] <BjornT> me
[01:02] <cprov> me
[01:02] <carlos> ME
[01:02] <salgado> I am
[01:02] <carlos> sorry for the caps
[01:02] <SteveA> kiko is on vacation
[01:03] <SteveA> ddaa is on vacation too
[01:03] <SteveA> stub?
[01:03] <niemeyer_> me
[01:03] <daf> Kinnison is on vacation, I think
[01:03] <fabbione> me
[01:03] <SteveA> he is, yes
[01:03] <SteveA> hi fabbione 
[01:03] <fabbione> i am always here
[01:03] <stub> Here
[01:03] <fabbione> MHUAAA 
[01:03] <SteveA>  * Roll call
[01:03] <SteveA>  * Agenda
[01:03] <SteveA>  * Next meeting
[01:03] <SteveA>  * Activity reports
[01:03] <SteveA>  * Items from last meeting
[01:03] <SteveA>  * Production / staging (stub)
[01:03] <SteveA>  * Requiring tests for merges. (lifeless)
[01:03] <SteveA>  * Keep, Bag, Change
[01:03] <SteveA>  * Three sentences
[01:03] <SteveA> 
[01:04] <SteveA> next meeting, 5 january, okay?
[01:04] <lifeless> ya
[01:04] <spiv> fine with me, I'll still be on leave ;)
[01:04] <jblack> aye
[01:04] <carlos> yep
[01:04] <stub> ok. I should be there (I fly back from Penang in the morning on the 5th)
[01:05] <SteveA> activity reports: how's all that going?
[01:05] <stub> Fine
[01:05] <jblack> up to date
[01:05] <lifeless> up to day
[01:05] <carlos> I'm two days behind with the activity reports
[01:06] <niemeyer_> I'm up to date
[01:06] <BjornT> up to date
[01:06] <matsubara> up to date
[01:06] <salgado> I'm up to date, I think
[01:06] <spiv> I'm behind.
[01:06] <SteveA>  * items from the last meeting
[01:06] <SteveA> i've been slack with the meeting summary from last week
[01:07] <SteveA> * RobertCollins to set up a bzr-for-launchpad meeting at a different time to the launchpad developers meeting.
[01:07] <lifeless> oh yea, right.
[01:07] <SteveA> * Kiko to set up a launchpad community meeting.
[01:07] <lifeless> I've been 'getting to that' all week.
[01:07] <SteveA> kiko's away, but this hasn't happened still
[01:07] <SteveA> * Steve to announce the production of last week's summary on the launchpad-users mailing list.
[01:07] <SteveA> no summary, no announcement :-/
[01:08] <stub> And me or Steve should schedule an infrastructure meeting when people are back from hols
[01:08] <SteveA> there was a wiki page set up for bzr-for-launchpad-development priorities
[01:09] <SteveA> i need to do some prioritization there
[01:09] <SteveA> mpt wrote a proposal about product groups / projects
[01:09] <SteveA> which now needs further discussion
[01:10] <SteveA> i think that's it
[01:10] <SteveA> i'd like to note that kiko and i now have access to change priorities on the admins' RT queue
[01:11] <SteveA> or rather, on the launchpad tasks queue in RT
[01:11] <jblack> Do you have time to describe the intended process a little? 
[01:11] <SteveA> this should give us a better quality of service for the things that are immediately important
[01:11] <SteveA> the intended process of getting admins to do RT stuff?
[01:11] <jblack> Of getting a bump
[01:12] <jblack> It went rough when you and I tried, because you didn't have the bug yet? 
[01:12] <SteveA> https://rt.admin.canonical.com/
[01:12] <SteveA> you can view the launchpad queue there
[01:12] <SteveA> the username and password is the same one as for the wiki
[01:12] <SteveA> the internal canonical wiki, that is
[01:13] <SteveA> so, when you add an rt issue, it gets put into a "pending classification" queue, that is not public
[01:13] <cprov> salgado: MM spec was updated with your answers
[01:13] <SteveA> when an admin has classified it, and put it in the 'launchpad' RT queue, then I or kiko can change its priority, and also change it in other ways
[01:14] <SteveA> i'm using a priority of 99 to mean "this should be the next thing in the admins' queue"
[01:14] <SteveA> and working down from there
[01:14] <SteveA> the idea is to have urgent things or blocking things registered with a priority of 99
[01:14] <SteveA> and to have a mix of quick and longer-term things there
[01:14] <SteveA> jblack: does that answer your question?
[01:15] <jblack> How do you want to be requested? 
[01:15] <SteveA> in order to make something a high priority, i need to understand why it is important
[01:15] <jblack> strictly email? both email and irc? 
[01:15] <SteveA> email or irc is okay
[01:15] <SteveA> irc, when i'm here and listening
[01:16] <SteveA> email when i'm not, and whenever
[01:16] <jblack> Thanks
[01:16] <SteveA> an email saying "RT issue X is important!" isn't much use unless we've already discussed that issue being important
[01:16] <SteveA> so, it's important to communicate the rationale
[01:17] <SteveA>  * Production / staging (stub)
[01:17] <stub> Asuka (the  server) was upgraded to breezy and PostgreSQL 8.0 earlier today. Expect it to be unavailable for the next few days as I test out PostgreSQL 7.4 -> 8.0 migration procedures and iron out the bugs.
[01:17] <stub> Gina has been run on production. Yay. Might need some love from the publishing scripts to be useful, as Gina just creates 'PENDING' packages.
[01:17] <SteveA> and let's talk about the gina run and bugzilla imports too
[01:17] <SteveA> are we using the launchpad dependencies package in production?
[01:18] <stub> Production update will happen Tuesday from head as of now, unless people require otherwise.
[01:18] <stub> As far as I'm aware, we are not using the launchpad dependencies package in production. That is elmo and Znarl's turf really.
[01:18] <SteveA> we should be using it
[01:18] <jamesh> I just put some updates for ErrorReportManagement up for review.  It might be nice to have that rolled out
[01:18] <SteveA> we should all be using it on our systems too
[01:19] <carlos> stub, universe
[01:19] <SteveA> what's the name of the package?
[01:19] <stub> jamesh: ok. I'll consider rolling out that revision when it lands.
[01:19] <sivang> SteveA: launchpad-dependencies
[01:20] <sivang> SteveA: and launchpad-database-dependencies
[01:20] <SteveA> thanks
[01:20] <SteveA> steve@einheit:~$ apt-cache policy launchpad-dependencies
[01:20] <SteveA> W: Unable to locate package launchpad-dependencies
[01:20] <SteveA> maybe it is only for dapper
[01:21] <daf> it's in dapper/multiverse
[01:21] <SteveA> i'll file an RT issue to ask the admins to use that package
[01:21] <stub> heh... it tells me I don't have bison and ncompress ;)
[01:21] <stub> I see it - probably it is in -backports or something
[01:22] <SteveA> on gina and bugzilla imports
[01:22] <SteveA> i'm concerned about the packages not being visible in the web app
[01:22] <SteveA> i don't know what needs to run to make them so
[01:22] <SteveA> i think we should not run the bugzilla import until these things are actually visible
[01:22] <SteveA> cprov: do you know anything about this?
[01:23] <cprov> SteveA: not much about bugzilla-import touched the code yesterday ...
[01:23] <SteveA> otherwise, i'll try phoning people who aren't here
[01:23] <stub> (launchpad packages are in breezy-updates)
[01:23] <SteveA> cprov: do you know what we need to do to get packages showing up in the web pages of launchpad?
[01:23] <dilys> Merge to devel/launchpad: [r=bjornt]  Soyuz/Buildd UI fixes, introducing batched list and ordering soyuz tests. (r2934: Celso Providelo)
[01:24] <cprov> SteveA: but of course we need a publisher run after gina imports to have "visible" pkgs
[01:24] <cprov> SteveA:  they need " publishing" transition from PENDING to PUBLISHED 
[01:25] <jamesh> so that's another script for stub to run?
[01:25] <SteveA> i'll see if i can talk with kiko later
[01:25] <cprov> SteveA: I'm not sure about the current status of RF publisher, but it works fine from my branch
[01:25] <stub> I think that requires Daniel in fact
[01:25] <cprov> scripts/publish-distro -Cvv -d ubuntu
[01:25] <SteveA> kiko will be able to say if it is okay to run on production
[01:26] <stub> ok. We have backups ;)
[01:26] <cprov> it will mode all PENDING to PUBLISHED and obviously create an archive 
[01:26] <lifeless> DoIt :)
[01:26] <SteveA> on this subject, https://wiki.launchpad.canonical.com/BugzillaImportProcess
[01:26] <cprov> move not mode 
[01:26] <niemeyer_> cprov: We should probably talk about that branch integration at some point
[01:26] <SteveA> a-moving on with the meeting...
[01:26] <SteveA>  * Requiring tests for merges. (lifeless)
[01:26] <cprov> niemeyer_: NOW ;)
[01:26] <niemeyer_> cprov: I mean, with Steve
[01:27] <lifeless> requiring test coverage in commits. Brought up by kiko two weeks back, has my complete support. The idea is that reviewers will be allowed to say
[01:27] <lifeless> 'this cannot be merged' based on test coverage, irrespective of other criteria.
[01:27] <cprov> niemeyer_: right, it probably requires some review team love 
[01:27] <lifeless> this needs lp management to say 'ok' before I can ask the review team to enforce it
[01:27] <lifeless> or its just dog-wagging.
[01:27] <SteveA> i'm more in favour of cat-swinging
[01:27] <SteveA> so +1 from me
[01:28] <lifeless> it has my +1.
[01:28] <lifeless> what does it need ?
[01:28] <SteveA> how about adding needs-tests as a pending reviews status
[01:28] <SteveA> (on cat swinging, see http://en.wikipedia.org/wiki/Cat_o%27_nine_tails)
[01:28] <sivang> please ping me when we discuss product-groups instead of projects..I have to attedn to something in the office :-/
[01:29] <lifeless> why the new state ?
[01:29] <SteveA> sivang: that's not on the agenda today
[01:29] <lifeless> I mean, the new tests will need review
[01:29] <lifeless> so its no different to 'not ready yet' from my perspective
[01:29] <sivang> SteveA: ah, ok. thanks
[01:29] <SteveA> i suggested it so that the fact that it's good to go except for tests is made clear
[01:29] <SteveA> i'm not attached to the idea
[01:30] <SteveA> quite possibly, it needs nothing other than a note in the reviewer guidelines
[01:30] <lifeless> I'll add  that to the next review meeting as a specific process question
[01:30] <SteveA> ok
[01:30] <lifeless> so - we have the go ahead on this ?
[01:30] <SteveA> also
[01:30] <SteveA> i'd encourage people to ask those who are good with tests, for help on how to write good tests for a branch
[01:30] <SteveA> while the branch is being worked on, even at the start
[01:31] <SteveA> it is a good discussion to have
[01:31] <lifeless> yes. this should go in the hacking faq too
[01:31] <SteveA> maybe add a "test plan" to specs?
[01:31] <lifeless> could do
[01:31] <SteveA> yes, you have the go-ahead with it.
[01:31] <SteveA> this is something to use common sense with
[01:31] <SteveA> and not be fanatical about
[01:31] <lifeless> of course.
[01:32] <SteveA> we all benefit from having better test coverage
[01:32] <SteveA>  * Keep, Bag, Change
[01:32] <lifeless> but before it was quite possible for someone to write 4K of pep8 ok code and get it 'oked'
[01:32] <SteveA> Bag: slacking off on meeting summaries
[01:33] <SteveA> anything else?
[01:33] <SteveA> 4
[01:33] <SteveA> 3
[01:33] <SteveA> 2
[01:33] <SteveA> 1
[01:33] <SteveA>  * Three sentences
[01:33] <daf> DONE: lots of bug triage, bug prioritisation, docs work on wiki
[01:33] <daf> TODO: more bug triage and prioritisation, land various branches, send list of headings to MPT
[01:34] <daf> BLOCKED: no
[01:34] <lifeless> DONE: b.l.n mirroring, several days of reviews, pqm on balleny
[01:34] <lifeless> TODO: story tests, test task list, baz2bzr
[01:34] <lifeless> BLOCKED: steveA-Zope3 update, week 5
[01:34] <matsubara> DONE: fixed bug on malone being unable to display a public bug that has a private dupe, fixed bug on spec name field triggering database constraint and other trivial bugs
[01:34] <matsubara> TODO: more bug fixing, merge most of the bugs above
[01:34] <matsubara> BLOCKED: nope
[01:34] <carlos> DONE: PoMsgSetPage, TranslationUploads merge (finally) and bug triage
[01:34] <jblack> DONE: supermirror initial rollout, some launchpad rocketfuel docs, lots of bzr support+mail
[01:34] <salgado> DONE: MirrorManagement, landed ProperSignUpWorkflow, code review, small fixes.
[01:34] <jblack> TODO: more of same, primarily rocketfuel
[01:34] <jblack> BLOCKED: None
[01:34] <spiv> DONE: Assorted supermirror stuff.
[01:34] <spiv> TODO: Supermirror, christmas!
[01:34] <spiv> BLOCKED: no
[01:34] <BjornT> DONE: fixed bugs in the email interface. landed reviewed branches. got started on reducing the number of statuses in the support tracker. reviews. general malone discussions.
[01:34] <BjornT> TODO: finish reducing the number of statuses and getting a decent test coverage of the support tracker.
[01:34] <BjornT> BLOCKED: no
[01:34] <carlos> TODO: PoMsgSetPage, TranslationReview, bug #5751
[01:34] <SteveA> DONE: management stuff, bug triage stuff, brad in vilnius stuff
[01:34] <SteveA> TODO: vacate, zope3 update
[01:34] <SteveA> BLOCKED: no
[01:34] <Ubugtu> Error: I cannot access this bug
[01:34] <carlos> BLOCKED: no
[01:35] <salgado> TODO: Finish first round of MirrorManagement tomorrow, then vacation
[01:35] <lifeless> muhahaha ubugtu muhhahaa
[01:35] <salgado> BLOCKED: no
[01:35] <jblack> ?
[01:35] <niemeyer> DONE: Soyuz work, Gantry discussions and researching, Smart 0.41 work and release, USA visa, etc
[01:35] <niemeyer> TODO: Vacation
[01:35] <niemeyer> BLOCKED: Nope
[01:35] <cprov> DONE: delivered/tested new queue script and old soyuz branch catch up
[01:35] <cprov> TODO: uploader-test clean up and review setup for this branch
[01:35] <cprov> BLOCKED: dapper-uploads generation (RT # 1310)
[01:35] <jamesh> DONE: SelectResults.__len__() removal, ErrorReportManagement stuff, team branch traversal fix, other bug fixes
[01:35] <jamesh> TODO: bugzilla import, code reviews
[01:35] <jamesh> BLOCKED: publishing run (before bugzilla import)
[01:35] <stub> DONE: fti rollout improvements
[01:35] <stub> TODO: PostgreSQL 7.4 -> PostgreSQL 8.0 migration testing
[01:35] <stub> BLOCKED: Nothing
[01:35] <bradb> DONE: Sprint in Vilnius with SteveA. Landed a few bugfixes. Landed InitialBugContacts.
[01:35] <bradb> TODO: Land status changes. Small bugfixes if time. Holidays.
[01:36] <bradb> BLOCKED: No.
[01:36] <SteveA> anyone else?
[01:36] <daf> TODO: get a festivus pole (http://www.festivuspoles.com/pages/Festivuspoles.htm)
[01:37] <SteveA> cprov: i'll ask about RT 1310
[01:37] <cprov> jamesh, stub, SteveA: maybe I can help with publisher if you can't contact Kinnison or kiko ...
[01:37] <SteveA> cprov: but this might be delayed until elmo is back
[01:37] <SteveA> thanks cprov 
[01:37] <cprov> SteveA:  this is BAD ...
[01:37] <SteveA> it is festvus tomorrow
[01:38] <SteveA> cprov: do you know if anyone other than elmo can do RT 1310 ?
[01:38] <cprov> SteveA: I was expecting the upload for the before the crew leave  
[01:38] <cprov> SteveA:  not that I know, it requires katie-fu
[01:39] <SteveA> i think infinity knows about katie
[01:39] <SteveA> also Kamion does
[01:39] <cprov> SteveA: could be, but he is also on leave, isn't he ?
[01:40] <cprov> SteveA: Kamion looks like a good bet, if he was available during this time 
[01:41] <sivang> DONE: Getting up to date with mailing list, some comments on RFS, going over some bugs, commenting and providing info.
[01:41] <SteveA> he's going to be around for the distro team meeting
[01:41] <sivang> TODO: Help matsubara reproduce spec tracker registeration bug , complete rockefuel checkout using jblack's script
[01:41] <cprov> SteveA: don't know if he can handle DC issues like anonymous rsync access setup and storage, but I hope so
[01:41] <SteveA> will anyone but elmo understand what is written in https://rt.admin.canonical.com/index.html?q=1310
[01:41] <lifeless> SteveA: any word on z3 ?
[01:41] <SteveA> lifeless: just "argh"
[01:42] <jblack> Anybody going to the FSF gplv3 meeting in Boston? 
[01:42] <sivang> BLOCKED: not enough time, still.
[01:42] <cprov> SteveA: yes, I think, if not call me anytime
[01:42] <SteveA> ok
[01:42] <SteveA> that's it then
[01:42] <SteveA> we have time for a countdown of doom today
[01:42] <lifeless> 0
[01:43] <SteveA> MEETING ENDS
[01:43] <daf> happy festivus everyone
[01:43] <SteveA> thanks folks.  have a vacation.
[01:43] <salgado> lifeless, do you have a few minutes? (there's one point from your review that I'd like to discuss. it should be quick)
[01:43] <lifeless> salgado: sure
[01:44] <carlos> ok
[01:44] <salgado> lifeless, in the subclass of GeneralFormView I've created, the default process() method shouldn't accept a *args, because it must be generic and it won't know how to handle that *args
[01:45] <salgado> lifeless, although, any subclass can override that method if they want to have *args. 
[01:45] <lifeless> salgado: its just unusual to see **kwargs without *args
[01:45] <lifeless> if its deliberate, I'd make a comment and its fine
[01:46] <salgado> lifeless, I thought about making the generic process method be "def process(self, *args, **kw)" and then raise an AssertionError if *args was provided
[01:46] <lifeless> note separately that **kwargs in hierarchives should be very juidiciously used. I haven't look at this region of code sufficiently to comment on it here yet
[01:46] <SteveA> *args and **kw are kinda evil
[01:46] <lifeless> SteveA: jinx!
[01:46] <SteveA> what's the reason for wanting them?
[01:47] <salgado> SteveA, 1sec. I'll paste it
[01:47] <salgado> SteveA, https://chinstrap.ubuntu.com/~dsilvers/paste/fileVJSuYl.html
[01:47] <lifeless> SteveA: its another general form concept
[01:48] <salgado> SteveA, it's a generic generalform that can be used for editviews
[01:48] <lifeless> SteveA: very similar to the existing general form, something I think we should look at at a sprint
[01:49] <BjornT> salgado: why can't you use SQLObjectEditView?
[01:49] <SteveA> salgado: what is going to call process() with kw args?
[01:49] <salgado> BjornT, because I want to do some schema validation
[01:50] <salgado> SteveA, GeneralFormView's process_form() 
[01:50] <BjornT> salgado: what kind of schema validation?
[01:50] <salgado> SteveA, BjornT, I also extended the GeneralFormView to make it easier to do schema validation
[01:51] <salgado> BjornT, check if at least one of three widgets is not-None
[01:51] <salgado> for instance
[01:51] <SteveA> i get worried when i see methods with generic names calling each other
[01:51] <SteveA> it becomes unclear what the division of responsibilities are
[01:53] <BjornT> i don't think that we should have both SQLObjectEditView and GeneralFormEditView, we should only have one of them.
[01:53] <salgado> SteveA, well, the GeneralFormView is pretty well documented, I think. it says clearly that if your processing should be done in the subclass' process() method
[01:53] <salgado> s/if your/your
[01:53] <lifeless> I think we need to review the structure of the general form stuff
[01:54] <lifeless> it has **kwargs in there already as I recall
[01:54] <salgado> lifeless, yes, it does
[01:54] <lifeless> and this new use is sympomatic of a flaw in the underpinnings
[01:54] <SteveA> i see
[01:54] <lifeless> rather than the introduction or regression of a concept
[01:54] <SteveA> also, there is an equivalent thinggie in the new zope3 code
[01:54] <SteveA> which we should adopt / improve
[01:54] <lifeless> which is why I am suggesting some intense pair face to face stuff to address this
[01:55] <lifeless> either that or someone who has spare cycles and a refactoring fetish to spend time on it now. But its not AFAICT a design or use problem in salgagos patch per se
[01:56] <salgado> I can't see how to make a generic form view without **kwargs, though
[01:56] <lifeless> salgado: it really depends what you want to factor out
[01:57] <lifeless> for instance, the current 'process' really is 'set_attributes_from_form_request_variables'
[01:57] <lifeless> which would not be a kwargs method
[01:57] <BjornT> lifeless: well, having two different edit view classes is confusing. i think we should create a new GeneralFormView when the new zope3 stuff lands, and until then it's better to customize SQLObjectEditView to fit salgado's use case
[01:58] <lifeless> BjornT: I've no opinion on that at this point. salgado - can you please look at that other view, and if they really are this close, and you think its safe to change, do as BjornT is suggesting
[01:58] <salgado> BjornT, we already have the SQLObjectAddView and the GeneralFormView
[01:59] <lifeless> salgado: I think BjornT is saying that there is already another SQLObjectEditView form
[01:59] <lifeless> salgado: which has the same role as your new class
[01:59] <BjornT> salgado: that's two different things. SQLObjectAddView is for adding things, GeneralFormView is for general form processing.
[01:59] <lifeless> salgado: so would rather tweak it to do what you need..
[01:59] <salgado> I don't think I'm making things more confusing with this patch
[01:59] <lifeless> if you two come to an agreement - cool
[02:00] <salgado> BjornT, but GeneralFormView can be used only for processing forms that create new objects
[02:00] <salgado> it can't be used in edit forms
[02:00] <salgado> I could easily change it so it can be used in edit forms
[02:01] <BjornT> salgado: you're adding an edit view with different semantics than the existing edit view. it's easy to customize the existing edit view to do what you like.
[02:01] <salgado> and then I'd do the generic part of my GeneralFormEditView in my own subclass of it
[02:04] <BjornT> salgado: mark told me that he didn't want us to create a GeneralFormEditView, and instead use the existing SQLObjectEditView. (i think we should create new form classes later with the new zope3 stuff, replacing the old ones, though)
[02:05] <salgado> BjornT, okay, what would be the better solution: customize SQLObjectEditView (in the same way I already did for GenericFormView), or change the GenericFormView so it can be used in editforms and do the actual processing in my GenericFormView's subclass?
[02:06] <BjornT> salgado: so, to sum up what i think. if you want to solve your use case generally, customize SQLObjectEditView. otherwise use GeneralFormView and do the extra processing in your specific view classes.
[02:07] <BjornT> salgado: remind me, why can't you use browser:generalform?
[02:07] <SteveA> stub, cprov: i just spoke with kiko about publisher runs etc.
[02:07] <salgado> BjornT, because it doesn't set the initial values
[02:07] <cprov> SteveA: so, what does he suggest ?
[02:08] <salgado> BjornT, initially, I simply changed it to set the initial values and was doing the processing on my own subclass
[02:08] <SteveA> let's talk on the c-m channel
[02:08] <salgado> BjornT, but then I got tempted to write something generic so I could share between all my subclasses (I have 3 of them in this patch, IIRC)
[02:08] <salgado> (subclasses of GeneralFormView, I mean)
[02:09] <BjornT> salgado: ok. let me take a quick look at it. although, if you have 3 classes that requires this, i would suggest to modify SQLObjectEditView to cover your use case.
[02:12] <stub> salgado: Any reason you didn't just extend GeneralFormView to make it more 'general'?
[02:13] <BjornT> salgado: the branch that you did these changes aren't on the PendingReviews page? i'd like to see the changes you did to GeneralFormView
[02:14] <stub> c/extend/enhance
[02:14] <salgado> stub, I did that. you can subclass it, define an 'initial' property and then it can be used in an edit form. but then I got tempted to write a generic editview that would also set the attributes back in your object when the form is submitted
[02:14] <salgado> BjornT, it's there but I forgot to mirror. I'll mail you the diff
[02:15] <salgado> BjornT, sent
[02:16] <BjornT> salgado: cool. because i think it's worth making GeneralFormView to set initial values, i just want to see how you did it.
[02:16] <SteveA> call it 'initial_values' or something more explicit than 'inintial'
[02:17] <salgado> the patch is at https://chinstrap.warthogs.hbd.com/~salgado/distro-mirror.diff too
[02:17] <salgado> (in case anybody else wants to look at it)
[02:26] <BjornT> salgado: why do you need two different error lists? (self.errors and self.schema_errors, where the first one actually contains errors related to the schema)
[02:28] <salgado> BjornT, because self.errors is for the errors that are going to be displayed as a box around the widget that triggered that error. while schema_errors has to be displayed at the beginning of the page, because it will probably apply to multiple widgets
[02:43] <BjornT> salgado: hmm, it's still a bad name. i can't think of a better name, though. in zope3 terms it would be invariant_errors, but since you don't use invariants directly, that doesn't seem right. i guess it's ok for now, and we can re-think it later.
[02:44] <SteveA> this is a view class
[02:44] <SteveA> so top_of_page_errors would work too
[02:44] <SteveA> outside_of_form_errors
[02:45] <BjornT> yeah, those are better names
[02:45] <salgado> I prefer top_of_page_errors
[02:45] <BjornT> salgado: so, i'd say, keep the modifications for initial values (renaming it to inital_values as SteveA suggested), but drop GeneralFormEditView.
[02:46] <salgado> BjornT, right, and keep using the GeneralFormView on my edit views or use SQLObjectEditView?
[02:47] <BjornT> salgado: i don't care if you modify SQLObjectEditView or do the logic in your specific view classes, do what's easiest for you to do. (modifying SQLObjectEditView would probably be the most useful solution, though)
[03:04] <SteveA> daf: hi.  do you want to do some more rosetta bug discussion today?
[03:04] <SteveA> carlos: how's the performance refactoring going?  want to talk about it at all?
[03:40] <salgado> BjornT, I changed SQLObjectEditView in the same way I did to GeneralFormView. would you review it for me?
[03:41] <BjornT> salgado: sure
[03:42] <SteveA> jamesh: does your import script convert default assignees to package bug contacts?
[03:42] <salgado> BjornT, mailed it to you
[03:42] <jamesh> SteveA: no.  I have a separate script for that
[03:42] <jamesh> which needs some small tweaks for InitialBugContacts
[03:43] <SteveA> what is the name of this script?
[03:43] <jamesh> it isn't in the launchpad tree at the moment
[03:43] <SteveA> i need a name for BugzillaImportProcess
[03:43] <jamesh> let me find it
[03:44] <jamesh> migrate-bugzilla-maintainers.py
[03:48] <Mez> o_O
[03:48] <Mez> I have a highlight in here?
[03:57] <SteveA> bradb_: where's the status changes branch up to?
[03:58] <bradb_> SteveA: #3 in pqm's queue
[04:02] <SteveA> bradb: please update https://wiki.launchpad.canonical.com/BugzillaImportProcess when it lands
[04:02] <bradb> SteveA: ok
[04:02] <jamesh> SteveA: I've got a second round of ErrorReportManagement changes in the review queue.  The main bits are: remove /errors/* pages, put day-of-month in oops ids, better handling of non-ascii data and the port of kiko's log analysis script
[04:05] <SteveA> jamesh: can we talk about the log analysis?
[04:05] <jamesh> sure
[04:05] <SteveA> i'm interested in NotFound errors where the Referer's host is one of the ones we care about
[04:06] <SteveA> to start with, that includes launchpad hosts, shipit, wiki stuff...
[04:06] <SteveA> anything with ubuntu.com or launchpad.net in the host name, i guess
[04:06] <SteveA> these indicate a bad link that we can fix
[04:07] <SteveA> i'm also interested in NotFound errors that aren't by robots
[04:08] <jamesh> should be pretty easy to get some regexps to detect search engine bots
[04:09] <jamesh> I suppose this could be presented in a report as "all NotFounds caused by bots", "all by humans", "some of each"
[04:09] <SteveA> 800 error reports for 2005-12-21
[04:09] <SteveA> some of each?
[04:09] <jamesh> the first and third cases usually indicating that we've changed links, the second usually being humans pruning URLs
[04:10] <jamesh> some NotFound errors caused by bots, some by humans
[04:10] <salgado> lunch
[04:12] <SteveA> Exception-Value: Unknown SQL builtin type: <class 'canonical.launchpad.database.milestone.Milestone'> for <Milestone at 0x2ab815cc10>
[04:12] <SteveA> this is a malone bug
[04:13] <SteveA> from the advanced search page
[04:13] <SteveA> chinstrap:/srv/gangotri-logs/2005-12-21/72434.A369
[04:20] <SteveA> https://launchpad.net/distros/ubuntu/+source/cnews/+bugs
[04:20] <SteveA> interestingly, that causes a system error
[04:23] <carlos> SteveA, about the suggestions thing... I'm changing most of the methods to use SQL queries, but I need some changes I did as part of the cleanup to implement PoMsgSetPage
[04:23] <cprov> more than that, https://launchpad.net/distros/ubuntu/+source/cnews also crashes
[04:23] <carlos> SteveA, so I'm going to add the changes for the suggestion part to the PoMsgSetPage branch
[04:24] <carlos> SteveA, the main thing is that with our current code, there are some situations when you don't have an IPOMsgSet and that's why Mark created the methods inside IPOTMsgSet
[04:25] <SteveA> but they are not used, as far as i can see
[04:25] <carlos> I added a DummyPOMsgSet object like the DummyPOFile that will let us to assume that we always have such object
[04:25] <carlos> SteveA, they are used
[04:25] <carlos> SteveA, the IPOMsgSet calls the IPOTMsgSet
[04:25] <carlos> methods
[04:25] <SteveA> yes
[04:25] <SteveA> so
[04:25] <SteveA> why?
[04:26] <SteveA> why have something exist just so it is called by something else?
[04:26] <carlos> well there are some of those methods that are also called from another part of the code... but I cannot give you a rationale as I didn't write that code
[04:26] <SteveA> i grepped the code for the methods i mentioned in that bug report
[04:27] <SteveA> and i cannot find them called
[04:27] <SteveA> that is why i talked about removing those methods from IPOTMsgSet
[04:27] <SteveA> and making them occur only in IPOMsgSet
[04:28] <carlos> that's what I'm doing, but for all the methods not just the ones that are called only from IPOMsgSet
[04:29] <carlos> so they are methods of the context they use
[04:30] <SteveA> okay, i think
[04:31] <SteveA> i don't really understand.  so long as you're making the code use SelectResults, make specific SQL queries, and only use shortlist() to listify things rather than list() or list comprehensions,
[04:31] <SteveA> then that sounds like good stuff
[04:32] <carlos> SteveA, well, the idea is to do SQL queries and nothing else
[04:32] <carlos> there are many python code that can be moved back to the DB
[04:32] <cprov> SteveA: where are the production error reports in chinstrap ?
[04:32] <carlos> so no more lists or sorting using python or getting a bunch of records to filter them out using python
[04:33] <SteveA> cprov: /srv/gangotri-logs
[04:33] <SteveA> carlos: sounds good
[04:33] <cprov> SteveA: thx
[04:33] <SteveA> carlos: it may be good to do this one step at a time, rather than all at once as a very big change
[04:33] <SteveA> such a change is harder to review
[04:35] <carlos> hmm
[04:35] <carlos> ok I will try to extract the needed bits from PoMsgSetPage branch and add them to this new branch
[04:35] <carlos> SteveA, ok?
[04:36] <SteveA> that will help reviewers
[04:37] <SteveA> so, please do so
[04:37] <SteveA> but also, consider breaking the refactoring into sql queries into smaller chunks
[04:42] <carlos> ok
[04:47] <dilys> Merge to devel/launchpad: [r=BjornT]  Malone bug status changes. See (r2935: Brad Bollenbach)
[06:24] <carlos> SteveA, dude... IPOMsgSet.getCurrentSubmissions is the same as IPOMsgSet.publishedSubmission
[06:24] <SteveA> wow
[06:24] <carlos> but using a lot of python code
[06:25] <SteveA> i see
[06:39] <SteveA> stub: staging seems rather dead
[08:02] <reed> hi there
[08:03] <reed> can somebody point me to a description of what Launchpad is and wether it is free (as in freedom) software?
[08:04] <reed> uhm, never mind, it seems that the wiki answers the first question :)
[08:05] <SteveA> launchpad isn't free software
[08:05] <dilys> Merge to devel/launchpad: [r=spiv]  fix bug 2676, work around python's unfolding of email headers, to make gpg signatures verify properly. (r2936: Bjorn Tillenius)
[08:05] <SteveA> it's like google or freshmeat: a free service but not free software
[08:08] <reed> SteveA: do you know if there are plans to release it as a free sw package?
[08:08] <reed> or also, would that make sense technically or is launchpad just too Ubuntu specific?
[08:11] <SteveA> there are no concrete plans
[08:11] <SteveA> mark shuttleworth has said that he wants it to be free software at some point in the future
[08:12] <reed> SteveA: thank you
[10:14] <cprov> night guys 
[11:09] <Hieronymus> https://launchpad.net/malone/assigned?name=motuscience points to my own assigned bugs. The page was linked to from https://launchpad.net/distros/ubuntu/+source/ghemical/+bugs