[12:01] <ddaa> Thanks
[12:01] <BradB> or mawson
[12:03] <BradB> it's amazing how far having tabs along the top of the page and portlets can make it look like you rewrote plone
[12:05] <limi> ;)
[12:05] <limi> BradB: do you use vim on OS X?
[12:05] <ddaa> Where's the "Plone Powered" link? ;-P
[12:05] <BradB> limi: I can, but I'm mainly an emacs guy.
[12:06] <BradB> ddaa: heh heh
[12:06] <SteveA> https://launchpad.ubuntu.com/doap/projects/canonical/malone
[12:06] <SteveA> two tabs
[12:06] <SteveA> selected
[12:06] <SteveA> I guess because both "projects" and "malone" are inthe url
[12:09] <BradB> SteveA: weird. i wondered what the logic behind that was.
[12:24] <daf> spiv_: woo, transactional zopeless!
[12:32] <ddaa> courtesy of taxi.py
[12:32] <ddaa> Now... if only I could get this import to go that far before hanging...
[12:46] <lifeless> ddaa: happy taxi's ?
[12:46] <ddaa> Not there yet :-(
[12:46] <ddaa> I ran an import not long ago and it just hung...
[12:46] <ddaa> And I have been carried away trying to debug the hang.
[12:46] <lifeless> strace -p pid - bet you a beer its waiting on a futex
[12:46] <ddaa> That's vague...
[12:46] <lifeless> if its waiting on a futex, its the Queue
[12:46] <ddaa> I'm tracing the damn thing with twisted spewage.
[12:46] <carlos> night!
[12:52] <ddaa> lifeless: regarding the hangs, I often have them after "launched local CVS server"
[12:52] <ddaa> Just not when I want them to happen of course.
[12:53] <ddaa> Is there any pyarch around there?
[12:53] <lifeless> after the local CVS server launches, there is an rlog call, which can take non-trivial time.
[12:54] <lifeless> there isn't any pyarch at that point.
[12:55] <ddaa> That's hang situation. Not impatience. No network traffic, no cpu usage, no i/o frenzy.
[12:55] <lifeless> ok, thats a concern then.
[12:55] <lifeless> what does strace show you ?
[12:55] <ddaa> Not stracing...
[12:55] <lifeless> (when I see that, its often very low cpu, but present)
[12:55] <ddaa> spewing, but it's working okay atm.
[12:56] <lifeless> ok, next time it happens, attach a strace to the slave before you kill it
[12:56] <ddaa> Well... I do have some background activity... so maybe I'm missing it... but that would suprise me very very much.
[12:56] <ddaa> Okay.
[12:57] <ddaa> If it's hung, I s'pose strace will show nothing, right?
[01:00] <lifeless> strace will show the call that hung
[01:00] <ddaa> Mh. Okay.
[01:01] <lifeless> if you see multiple processes as the slave (old style threads), attach to them all, one will be the slave event loop, and not helpful.
[01:01] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: translationsPortlet implemented and inserted into SourcePackage page. Closes bug #2139 (patch-702)
[01:01] <ddaa> lifeless: yeah... I have many such threads most of the time...
[01:02] <dilys> Bug 2139 resolved: Rosetta link (portlet?) for Soyuz Source Package index
[01:02] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2139
[01:17] <lifeless> buy a hoverbook
[01:17] <lifeless> goes well with the massage-keyboard
[01:17] <limi> maybe tla will finally not be dog-slow if he gets a Powerbook ;)
[01:17] <lifeless> he has a powerbook at the moment
[01:18] <ddaa> a iBook actually... and so does bob2
[01:18] <limi> ...running Linux ;)
[01:18] <ddaa> we just happen to be using a real operating system :-P
[01:18] <lifeless> limi: of course.
[01:18] <limi> a real operating system that doesn't support the wifi card in the Powerbook :P
[01:18] <ddaa> btw, you guys cannot recognize great technology. Touch keyboards are the future.
[01:19] <ddaa> Well... maybe... they are maybe a bit awkyard with legacy layouts...
[01:22] <ddaa> limi: my ibook does not have wifi. That's the main problem.
[01:22] <ddaa> I was cheap when i bought it.
[01:22] <ddaa> And get your fruit company to be a bit more tight assed when it comes to hardware specs.
[01:23] <ddaa> *a bit less
[01:55] <kiko> heh
[01:55] <kiko> yeah
[02:54] <limi> kiko: you're a vim user, right?
[02:55] <kiko> limi, indeed I am.
[02:55] <limi> trying to make the switch ;)
[02:55] <limi> is there an autocomplete HTML mode/plugin available?
[02:55] <limi> found this: http://vim.sourceforge.net/scripts/script.php?script_id=301
[02:56] <limi> and put it in my .vim/ftplugins
[02:56] <limi> but nothing happens :] 
[02:56] <limi> <-super-newbie
[02:57] <limi> kiko: and you are the kind of person that requires nick highlight too, right? ;)
[02:57] <kiko> yeah, because 1000 people want to talk to me all the time in 50 differnet channels :)
[02:58] <limi> hehe
[02:58] <limi> I can sympathize ;)
[02:58] <limi> kiko: anyway, what do you use for HTML editing in vim?
[02:58] <kiko> hmmm
[02:59] <kiko> nothing much, to be honest. 
[02:59] <limi> kiko: autocomplete and tag matching is what I need - if it supports folding, that's a bonus :)
[02:59] <limi> ok
[02:59] <kiko> that script looks pretty cool
[02:59] <limi> kiko: but is there a special magic to activate an ftplugin?
[03:00] <kiko> placing it in your /ftplugin dir should work, I suspect
[03:01] <limi> kiko: it's in ~/.vim/ftplugin/ now, but I see no love - I suspect you need to put it into XML mode or something?
[03:01] <kiko> hmmm
[03:01] <kiko> there seems to be something in html.vim there
[03:02] <kiko> I can take a look a bit later and test it myself, will let you know of the results
[03:03] <limi> hm, seems to be a file extension thing
[03:03] <limi> works if I have an .html file
[03:03] <limi> thanks :)
[03:05] <kiko> yes
[03:05] <kiko> you can :set filetype=html if you want to force that
[03:05] <kiko> and you can set hooks in your .vimrc that do that for you
[03:06] <limi> ok
[03:07] <limi> kiko: and the extension -> filetype mapping is done where? need to define .pt as XML :)
[03:07] <kiko> you can just set it manually in your .vimrc
[03:07] <kiko> au! BufRead,BufNewFile *.ptl set filetype=python
[03:07] <kiko> au! BufRead,BufNewFile *.pt set filetype=html
[03:07] <limi> aha
[03:07] <limi> thanks :)
[03:09] <limi> there we go :)
[03:09] <kiko> cool
[03:20] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.3: now we have the name, propogate it throughout (patch-1)
[03:26] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.3: s/baz/bazaar in file names (patch-2)
[03:38] <dilys> Merge to thelove@canonical.com/dists--bazaar--0: propogate name change (patch-1)
[03:49] <kiko> thelove?
[03:57] <lifeless> thelove beby
[03:57] <lifeless> thelove
[03:57] <lifeless> https://www.warthogs.hbd.com/Bazaar
[03:58] <kiko> nice!
[04:01] <kiko> lifeless, I can't say how much I think you rock for starting this.
[04:01] <lifeless> thank you. Mark gave me the chance and the prod.
[04:02] <kiko> can we get an inventory of the patches applied to it so far?
[04:02] <lifeless> there aren't any yet.,
[04:02] <kiko> I mean, a list with a summary of descriptions 
[04:03] <lifeless> still bootstrapping the name change.
[04:09] <kiko> I see. I imagine we'll keep one, or would we be using tla inventories to browse them?
[04:10] <lifeless> I'm not sure what you are looking for specifically.
[04:10] <lifeless> if you mean a changelog - what features are added, the changelog for it should be sufficient.
[04:11] <lifeless> we will be maintaining a separate list of UI forward-compatible-breaking changes.
[04:11] <kiko> that's that I'm thinking, yes.
[04:12] <lifeless> have a look at the draft web page, its linked from the bazaar page.
[04:12] <kiko> I saw it, yeah.
[04:12] <lifeless> theres a section on it just for that.
[11:06] <carlos> morning
[11:17] <Kinnison> Hi carlos
[11:20] <Kinnison> Right; which database should we be using on mawson?
[11:36] <SteveA> elmo: ping?
[11:37] <Kinnison> What's a futex and why would gzip be waiting on one?
[11:38] <SteveA> a future mutex?
[11:39] <ddaa> fast mutex, that's a linux kernel thing.
[11:39] <SteveA> "fut alors"
[11:39] <Kinnison> Right; 'cos apt-ftparchive gets stuck
[11:40] <Kinnison> and this is irritating because it's why my test-run didn't finish
[11:41] <ddaa> http://ds9a.nl/futex-manpages/futex2.html
[11:42] <ddaa> 	The sys_futex system call provides a method for 	a program to wait for a value at a given address to change, and a 	method to wake up anyone waiting on a particular address. While the 	addresses for the same memory in separate processes may not be 	identical, the kernel maps them interally so the same memory mapped in 	different locations will correspond for 	sys_futex calls.  Futexes are typically used to 	implement the contended case of a lock in shared 
[11:49] <Kinnison> So can I stop it using them since it's clearly broken?
[11:51] <ddaa> I'd rather suspect a userspace bug.
[11:52] <Kinnison> LD_ASSUME_KERNEL=2.4 .....
[11:52] <Kinnison> seems to let it get on with things and run
[11:53] <ddaa> evil... but good to know you can do that...
[11:53] <Kinnison> aye
[11:53] <Kinnison> but for now at least; my test run might complete
[11:56] <Kinnison> apt-ftparchive is doing its job :-)
[12:08] <elmo> Kinnison: upgrade your gzip
[12:08] <elmo> it's #1854
[12:08] <Kinnison> elmo: zhongshan
[12:09] <elmo> meh
[12:09] <Kinnison> :-)
[12:09] <Kinnison> Done. 8000MB in 13533 archives. Took 15m48s
[12:09] <Kinnison> w00 w00 w00
[12:09] <elmo> fixed
[12:09] <Kinnison> spankyou
[12:10] <Kinnison> elmo: zhongshan still has that odd "apt-extracttemplates /var/cache/apt/archives/libc6-dev_2.3.2.ds1-13ubuntu2_i386.deb" running
[12:11] <Kinnison> well; s/running/in the process table/
[12:11] <elmo> yeah, it doesn't matter
[12:12] <ddaa> do you know if rsync --link-dest also detects renames?
[12:24] <Kinnison> elmo: Could you look at zhongshan:~dsilvers/apt.conf and tell me if it looks sane to you? It built zhongshan:~dsilvers/dists/... :-)
[12:58] <stub> Kinnison: launchpad_dogfood
[12:58] <Kinnison> stub: gotcha
[12:59] <SteveA> elmo: did you lock the wiki yet?
[01:00] <elmo> yes, just managed to.  moin was being.. uncooperative
[01:02] <SteveA> ok.  I've just been chatting to enrico
[01:02] <SteveA> he's going to announce a plan to the docs mailing list
[01:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: File list publishing for lucille (patch-703)
[01:29] <SteveA> elmo: I need to get a little food.  After that, I'm going to set up cacheing in plone, following vika's instructions.
[01:29] <SteveA> elmo: There are some changes need to the apache config.  I'll mail those to you in a bit.
[01:30] <elmo> ok, cool
[01:32] <SteveA> but, I suggest not to do them until I've done the plone set-up
[01:32] <SteveA> the cool thing is, I don't think I even have to restart plone
[01:49] <lifeless> here
[01:49] <ddaa> I got the result of the taxi test.
[01:49] <lifeless> good/bad/indifferent ?
[01:49] <ddaa> psycopg.OperationalError, FATAL:  database "launchpad_ftest" does not exist
[01:49] <lifeless> spiv_: around?
[01:50] <spiv_> Yeah.
[01:50] <lifeless> ^^^^^^^6
[01:50] <spiv_> It's using the default value from canonical.lp.dbname.
[01:50] <ddaa> I need to doublecheck some stuff, but at first I find that suprising since job loading is done from the database.
[01:50] <lifeless> ddaa: taxi runs in the other process
[01:50] <spiv_> ddaa: Ah... but job loading happens in the master.
[01:50] <lifeless> completely decoupled
[01:50] <spiv_> Including decoupled configuration of things like databases :)
[01:50] <ddaa> spiv_: other threads do not use the same value of canonical.lp.dbname?
[01:51] <lifeless> ddaa: threads have nothing to do with this ?
[01:51] <spiv_> ddaa: What else accesses the db from the slave?  I thought the slave got its directions from the master?
[01:52] <ddaa> lifeless: I do not know what has to do with what, but if the only db name used is read from the canonical.lp module, and that module is loaded only once, I cannot see how that can happen.
[01:52] <lifeless> spiv_: nothing else in the slave talks to the db
[01:53] <lifeless> ddaa: is the slave running from the same checkout as the master ?
[01:54] <ddaa> lifeless: I do not see how it could be differently, and anyway I do not see how that would be relevant. The database name is set in master.cfg immediately after first importing launchpad.db.
[01:54] <lifeless> ddaa: *thats in the master*
[01:54] <ddaa> Ha...
[01:54] <lifeless> *taxi is in the slave*
[01:54] <ddaa> Okay.
[01:54] <lifeless> get much sleep last night ? :)
[01:54] <ddaa> Then how should I configure that in the slave?
[01:55] <ddaa> Not much... I stayed up waaay to late looking for a french place to buy the specific lappy I'd like.
[01:55] <ddaa> I'm not sure I'd get the full benefit of the garantee if I buy it from some other country...
[01:56] <ddaa> Soooooo... spiv_? What's the place to set the dbname for the slave?
[01:57] <spiv_> ddaa: canonical.lp.dname ;)
[01:57] <ddaa> I'd very much prefer something that does not involve hardcoding settings...
[01:58] <ddaa> maybe that data could be passed down the wire... e.g. in the Job?
[01:58] <spiv_> Yeah, it probably could be.
[01:59] <ddaa> So, if I just put an additional attribute in the job loaded from the master, it's going to be accessible by the slave? The job is pickled or something then passed on the wire?
[02:00] <spiv_> Or make a sitecustomize.py that overrides it ;)
[02:00] <lifeless> ddaa: no, don't pass it to the Job
[02:01] <lifeless> in production that would be a PITA.
[02:01] <lifeless> a sitecustomize.py is more appropriate.
[02:01] <ddaa> spiv_: Please explain. I want all configuration to stay in the botmaster directory. You suggest putting an optional module there and have buildbot try to load it?
[02:02] <ddaa> Mh... actually, it should be in the slave's directory...
[02:02] <spiv_> echo "import canonical.lp; canonical.lp.dbname='blah'" > sitecustomize.py; PYTHONPATH=. twistd etcetc...
[02:03] <ddaa> I see. I'd load that information from Job.py?
[02:03] <ddaa> In runJob, maybe?
[02:03] <spiv_> (When starting up, i.e. before running a program, python will try to import sitecustomize, so if you have it somewhere on your PYTHONPATH...)
[02:03] <ddaa> Ha. Thanks, I was not aware of that.
[02:04] <spiv_> It's a bit of hack to do it that way.
[02:04] <spiv_> I think perhaps mixing configuration and code like we currently are with canonical.lp.dbname is not ideal.
[02:04] <ddaa> It will be time to change it later if there is a need for other sitecustomize...
[02:05] <ddaa> A spiv_: sure, canonical.lp could be modified to try to load e.g. lp_config and get hostname and dbname from there if it's available in the pythonpath.
[02:06] <spiv_> Right.
[02:06] <ddaa> spiv_: should not be very difficult to do...
[02:06] <spiv_> But the details should be debated on the launchpad list, I think.
[02:06] <spiv_> I suspect SteveA and others will have useful insights here.
[02:07] <ddaa> Okay. I'll write a message to launchpad@ right now.
[02:07] <spiv_> Another option would be to read them from environment variables.
[02:08] <ddaa> And I'll do the sitecustomize.py thing  in the meantime.
[02:08] <ddaa> [env]  yeah, I'll suggest that too.
[02:08] <ddaa> But I think loading a file is simpler.
[02:08] <lifeless> file please
[02:09] <ddaa> Harder to get wrong.
[02:13] <SteveA> can we use ZConfigure for everything, and have one standard launchpad.conf file ?
[02:13] <SteveA> and not lots of files for different purposes
[02:15] <spiv_> SteveA: That'd be great if every upstream package we used (e.g. Twisted, Buildbot) already used ZConfigure :)
[02:15] <spiv_> But unfortunately that's not the case.  Buildbot's config stuff is a bit of a mess, too.
[02:16] <SteveA> why can't *we* use ZConfigure?
[02:16] <SteveA> we're not using any of these tools in the raw.  Can't we write our own script to start buildbot using our own config?
[02:17] <spiv_> Buildbot's a nasty case, config-wise.  It really is a bit of mess that I wouldn't want to touch without a couple of days to properly fix it.
[02:18] <spiv_> (Maybe it's been fixed in upstream SVN, though..?)
[02:18] <spiv_> Are there any good docs on ZConfigure, btw?
[02:18] <SteveA> yes
[02:18] <SteveA> wonderful docs
[02:18] <lifeless> I'm perfectly happy with customised lp.__init__
[02:19] <lifeless> and if we spend more than 10 minutes fixing it, we've already blown the cost of customising two installs 5 times over
[02:19] <spiv_> lifeless: Which is my point stated much more directly :)
[02:20] <lifeless> 2149-2220
[02:20] <lifeless> thats 30 minutes
[02:20] <spiv_> :)
[02:21] <spiv_> SteveA: Sorry, I was fishing for a hint as to their location, rather than their existence :)
[02:28] <Kinnison> SteveA: are we having a meeting; or can I go to the post office; bank; etc. ?
[02:50] <stub> ddaa: The launchpad_ftest database won't exist atm. unless you use a test harness that sets it up and tears it down, such as canonical.launchpad.ftests.harness
[02:51] <ddaa> stub: you are referring to my post on launchpad@?
[02:51] <stub> I'm working on a branch making this saner atm
[02:51] <Kinnison> On mawson are we changing lib/canonical/lp/__init__.py to say launchpad_dogfood instead?
[02:52] <ddaa> I do not want to use launchpad_ftest
[02:52] <ddaa> I want to use a persistent database for development purpose. aka launchpad_dev.
[02:52] <stub> oh... sorry. I have test suites on my mind :-)
[02:53] <stub> Yes - canonical.lp.__init__.py should not have launchpad_ftests in there.
[02:53] <ddaa> It's a sane default to have.
[02:53] <ddaa> esp. if the db does not exist!
[02:54] <stub> Hmm... maybe. The branch I'm working on currently sets it to whatever is specified in the LP_DBNAME environment variable, or launchpad_dev if it isn't set. I'm currently bogged down in repairing unit tests though
[02:54] <ddaa> Actually, a sane default would probably be something that cause a failure if not overriden... but that's still another issue.
[02:54] <BradB> I would have changed that if it were referencing launchpad_dev, like the Makefile and ZCML were. :)
[02:55] <elmo> BradB: if we're making $anotherdomain.$tld, can we use one of the existing plones, or do we need a third instance?
[02:55] <ddaa> I love "aba change-version", it's really a basic building block for my methods.
[02:56] <lifeless> ddaa: raw switch
[02:56] <ddaa> Will switch ;-) as soon as I have cleared up the "asap" stuff.
[02:56] <stub> ddaa: I think I'll try that (dbname=None unless overridden in lp/__init__.py) and see what happens
[02:57] <ddaa> stub: => launchpad@
[02:57] <SteveA> Kinnison: we'll be having a meeting.  If you want to go to the I guess you can report first
[02:58] <Kinnison> SteveA: Okay; cool
[02:58] <BradB> elmo: I'd make another instance.
[02:58] <stub> ddaa: Hehe... you chose exactly the same env variable I did (or did that patch get to rocketfuel?) :-)
[02:58] <ddaa> stub: maybe that's just because it's the obvious name?
[02:58] <elmo> BradB: meh.  how would I make another instance?  I guess I can just copy most of it, but what about Data.fs ?
[02:59] <BradB> bin/mkzopeinstance.py
[02:59] <carlos> spiv_: is normal that the default database for zopeless is dbname = "launchpad_ftest" ?
[03:00] <BradB> elmo: Is this intended to be the same site just with a different name?
[03:01] <elmo> BradB: no, different site
[03:01] <SteveA> hello.  welcome to this week's launchpad meeting.
[03:01] <BradB> Yeah, so bin/mkzopeinstance.py
[03:01] <SteveA> all present, please say "aye!"
[03:01] <BradB> aye!
[03:01] <debonzi> aye
[03:01] <stub> eye
[03:02] <lifeless> eieieio
[03:02] <SteveA> (old macdonald had a sheep, e i e i o) ?
[03:02] <lifeless> and on that sheep there was a farm, eieio
[03:02] <SteveA> carlos: ?
[03:02] <SteveA> daf sends apologies
[03:03] <ddaa> yodeleitooooo
[03:03] <SteveA> spiv_: ?
[03:03] <Kinnison> aye
[03:03] <SteveA> to start with, a couple of announcements.
[03:04] <SteveA> I'm off on vacation from tomorrow, back on 8th
[03:04] <SteveA> Mark is away at a conference in Germany, and then in South Africa, back on 8th
[03:04] <lifeless> #1 & #2 gone... 
[03:04] <SteveA> Stuart has agreed to be the head launchpad dude until then.
[03:05] <SteveA> Let's agree on the time and date of next week's launchpad meeting now,
[03:05] <carlos> SteveA: yes
[03:05] <carlos> I'm here
[03:05] <SteveA> hi carlos
[03:05] <SteveA> How about Wednesday, 1230 UTC? 
[03:06] <Kinnison> sounds good
[03:06] <BradB> sure
[03:06] <carlos> ok
[03:06] <SteveA> launchpad-brazil ?
[03:06] <debonzi> no problem for me
[03:06] <SteveA> stub: ?
[03:07] <ddaa> lifeless: infoImporter and infoUpdater changes sent to pqm.
[03:07] <stub> I can do that, although earlier is good if it doesn't put brazil out.
[03:07] <debonzi> cprov is comming in some minutes but I think is not a problem to him to
[03:07] <lifeless> ddaa: great
[03:07] <SteveA> debonzi: 1200 ?
[03:08] <SteveA> would 1200 be okay instead of 1230?
[03:08] <debonzi> SteveA, ok too..
[03:08] <ddaa> lifeless: the infoUpdater worksforme, but I have not actually tested that it did not change jobs that are not in the "unassigned" product. But that's what the code should do.
[03:08] <SteveA> ok, let's so 1200
[03:08] <lifeless> ok, warning heard
[03:08] <lifeless> lets not confuse the lunchbox guys by interrupting too much.
[03:08] <ddaa> tell me if you want additional "interactive python" support.
[03:09] <SteveA> next, summary of the last meeting
[03:09] <carlos> SteveA: perhaps it's too early for daf
[03:09] <SteveA> it's on my todo list -- and I still haven't to-done :-/
What's the right place to talk then?</interrupt>
[03:09] <SteveA> carlos: daf isn't here.  so, he doesn't get a say :-p
[03:09] <carlos> ok ;-)
[03:09] <SteveA> hi Ki
[03:09] <SteveA> hi kiko
[03:09] <kiko> hello SteveA
[03:10] <lifeless> ddaa: private chat to me I guess
[03:10] <Kinnison> SteveA: 1200 is okay by me
[03:10] <SteveA> Kinnison: are you okay to talk yet?
[03:10] <Kinnison> yep
[03:10] <SteveA> ok.  before we start, the theme of this meeting is "dogfood"
[03:11] <Kinnison> Right
[03:11] <lifeless> mmmm
[03:11] <Kinnison> To that end; my primary concern is getting the librarian going on mawson
[03:11] <kiko> can it also be "soyuz is protected in an SEP field"? :)
[03:11] <Kinnison> I'm about 20 minutes off completing that :-)
[03:11] <SteveA> go for it, Kinnison
[03:12] <Kinnison> Okay; so things I know about for dogfooding on mawson...
[03:12] <Kinnison> librarian is needed -- I'm working on that now
[03:12] <Kinnison> gina -- I've got a patch floating for the build stuff; as soon as I'm told she can import against the current schema I'll polish it and commit it
[03:12] <Kinnison> Getting lucille to publish the contents of the dogfood db will take a little more work
[03:13] <Kinnison> I now have a completely published archive successfully on zhongshan
[03:13] <Kinnison> so I need to script the publishing process and then I'll be in a position to start the publishing on mawson
[03:13] <Kinnison> But that kinda wanders back into my expected lucille plan really
[03:13] <Kinnison> If anyone wants me to do anything else for mawson in the short-term; can you say *NOW* please?
[03:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: transactional infoImporter, tweak infoUpdater for production use (patch-704)
[03:14] <Kinnison> dilys: thanks babe.
[03:15] <Kinnison> SteveA: right; that's about it wrt. dogfood then
[03:15] <Kinnison> SteveA: in more general terms; my plans for lucille for the coming week are...
[03:15] <Kinnison> 1. Get the lucilleconfig columns populated and get the canonical.lucille.Publisher class generating apt.conf files for apt-ftparchive
[03:16] <Kinnison> 2. Design the version domination algorithm (mostly stealing from katie if elmo will let me)
[03:16] <BradB> Kinnison: stub probably wants to automate the code upgrade/db upgrade/data migration stuff on mawson.
[03:16] <Kinnison> 3. Get domination stuff.
[03:16] <Kinnison> BradB: for the most part; that shouldn't affect me much
[03:17] <Kinnison> oh and somewhere in there I need to split launchpad/{database,interfaces}/publishing.py into more manageable chunks and get my pending patch cleaned up to be integrated
[03:17] <Kinnison> But that shoudl be it.
[03:17] <Kinnison> phew.
[03:17] <kiko> splitting up publishing would be appreciated, cool
[03:18] <SteveA> domination is what was called overrides?
[03:18] <Kinnison> SteveA: No
[03:18] <Kinnison> Domination is the process by which the new version of a package ousts the older version from the archive
[03:18] <Kinnison> This is related to it having been built cleanly on all architectures etc.
[03:19] <kiko> really?
[03:19] <kiko> I never heard that term. and what do you mean by ousts? becomes the new "current"?
[03:20] <Kinnison> kiko: Yes; that's what I mean
[03:20] <kiko> I see. 
[03:20] <Kinnison> kiko: I haven't used the term before; so you won't have heard it yet :-)
[03:20] <kiko> well, one thing that does happen is different versions of current for different architectures. does that fit in with your reasoning?
[03:21] <Kinnison> Yes
[03:21] <Kinnison> It's all to do with the Pending,Published,Superceded,PendingRemoval state machine in the publishing tables
[03:21] <kiko> I was just lead off by your phrase "on all architectures". 
[03:21] <kiko> yeah.
[03:22] <Kinnison> But I fear we're getting off-topic here :-)
[03:22] <SteveA> BradB: you've been forging ahead with the set-up on mawson.  Can you talk a bit about that, what people need to do, and what is still to be done?
[03:22] <BradB> hm
[03:22] <BradB> I put a new code drop on mawson late yesterday
[03:22] <BradB> elmo needed to do something things for some people, and I think that's mostly (if not all) done.
[03:23] <BradB> stub (and whoever else) need to come up with the policy for how we're going to update the code and update the db schema and do data migration
[03:23] <BradB> some discussion was started on lp@ about this, but last i checked, no firm decision reached
[03:23] <cprov> sorry, I'm late
[03:23] <BradB> not sure if mark wants a hand in that
[03:23] <SteveA> hi cprov
[03:24] <BradB> so, here's the problem:
[03:24] <stub> data migration and db schema upgrades should be no problem - we went through the issues at oxford. I just need to write some fairly minor code.
[03:24] <SteveA> we need to decide and get stuff working before mark gets back
[03:24] <BradB> oh, ok
[03:24] <BradB> indeed
[03:24] <BradB> so yeah, for us, the data on the dogfood server is "production" data (...goes to get link...)
[03:24] <cprov> hi, steve... did I miss something important ? (debonzi is doing a report ...)
[03:25] <BradB> https://launchpad.ubuntu.com/doap/projects/canonical
[03:25] <SteveA> cprov: not really.  main thing is "dogfood", and making sure we can get there soon
[03:25] <BradB> If you get a 403, you need to install the client cert.
[03:25] <Kinnison> Where do we get the cert from?
[03:25] <BradB> It was mailed to lp@
[03:25] <BradB> from elmo, with love
[03:25] <cprov> SteveA: ok
[03:26] <BradB> launchpad.p12
[03:26] <BradB> and um, what else
[03:26] <BradB> oh, all bugs are to be filed in malone now
[03:26] <BradB> SteveA: ^ for packages too?
[03:27] <SteveA> is malone running and ready to go?
[03:27] <BradB> it's on there, yes.
[03:27] <stub> We appear to have the sample data loaded. Is that a good thing?
[03:27] <BradB> is it "stable" yet? no. but we still want to start asap.
[03:27] <BradB> stub: I don't think it's a bad thing.
[03:27] <Kinnison> BradB: I've imported the cert; but I still 403
[03:28] <BradB> stub: If it needs to be init'd in some other way (and it does), I don't know how to do it.
[03:28] <carlos> Kinnison: restart your browser
[03:28] <carlos> Kinnison: I had that problem and the restart worked
[03:28] <Kinnison> carlos: oh
[03:28] <Kinnison> carlos: you tock
[03:29] <Kinnison> carlos: you rock too
[03:29] <carlos> :-P
[03:29] <BradB> and i guess the one other thing is that it'd be nice if we could run Launchpad with bin/launchpadctl {start,stop,restart}, for which I've filed a bug.
[03:29] <stub> I suspect we want the sample data, if for no other reason all our accounts are in there.
[03:29] <BradB> I'm not in that sample data, last I checked.
[03:29] <BradB> Maybe I should add me. :)
[03:30] <carlos> stub: perhaps it's better don't use sample data and create the accounts with the script we have for that...
[03:30] <kiko> neither am I IIRC
[03:30] <BradB> anything else people need to know about the mawson deployment/
[03:30] <kiko> and I would rather not use sample data, I think
[03:31] <BradB> stub: Oh, I haven't tested your mail thing on there yet...not sure how that works "out of the box."
[03:31] <stub> ok. I'll rebuild launchpad_dogfood (?) with an empty schema, in which case we need to create accounts for everyone.
[03:31] <BradB> SteveA: Are we reporting all package bugs in Malone now too then?
[03:32] <BradB> stub: yes, launchpad_dogfood
[03:32] <SteveA> what do you mean by "package bugs" ?
[03:32] <BradB> Oh, and launchpad.u.c is the *only* dogfood app running on mawson. Rosetta alpha is intended to migrate to that instance as well.
[03:32] <BradB> SteveA: bugs in ubuntu source packages
[03:33] <BradB> afterall, we can use malone to report malone bugs, but it's not really meant for that.
[03:33] <stub> BradB: I think the email delivery is solid and dogfoodable if the nofications now have valid to and cc's being set (it was still hardcoded to you when I last played with it)
[03:33] <SteveA> I think that's mdz's call
[03:33] <carlos> BradB: will that dogfood database preserved until the final release?
[03:34] <BradB> carlos: yes, it's definitely not intended to be blown away from today. :)
[03:34] <stub> BradB: Might be worth leaving it off though if we arn't sure - don't want to have forgotten a hardcoded 'owned=1' and spam poor Mark :-)
[03:34] <carlos> BradB: then it will be Rosetta beta :-)
[03:34] <carlos> I mean, we will move with the beta release
[03:35] <BradB> stub: yeah, that's a bug I'll have to fix soonish (and it's a bug that I don't think is only limited to Malone.)
[03:35] <Kinnison> SteveA: if I head off to the post office etc now; can you send a meeting summary to me by email?
[03:36] <SteveA> Kinnison: sure -- well, I can at least manage the verbatim log.
[03:36] <SteveA> maybe even a summary
[03:36] <Kinnison> heh
[03:36] <Kinnison> cool
[03:37] <SteveA> lifeless: pong
[03:37] <lifeless> ->bazaar ?
[03:37] <SteveA> carlos: what's been happening with rosetta.  you did a bug triage of all the open bugs.
[03:37] <carlos> SteveA: yes
[03:38] <carlos> we added times when it was possible
[03:38] <SteveA> what important things are left?
[03:38] <carlos> added missing tasks
[03:38] <SteveA> do you have an idea now of when you'll be able to start a rosetta beta?
[03:39] <carlos> at this moment I think we have three main bugs to move to a beta (so it works, but there will not be all features yet)
[03:39] <carlos> I mean, if it's needed
[03:40] <carlos> but following the plan we have 19 bugs left
[03:40] <SteveA> and how much time for the three main bugs, in total?
[03:40] <carlos> but as I said "critical", about 3 bugs
[03:40] <cprov> carlos: are you using the Gina/Nicole dump ? Any remarks ?
[03:41] <carlos> I hope I will be able to fix two bugs today
[03:41] <carlos> the later is the bigger and implies the use of cprov's data
[03:41] <carlos> cprov: not yet
[03:41] <carlos> SteveA: I forgot one, there are  4 critical bugs/tasks
[03:42] <kiko> carlos, debonzi wrote a pretty neat little portlet for rosetta
[03:42] <carlos> the one to export the user data and import it into the new dogfood database
[03:43] <carlos> SteveA: but I think we should try to fix all bugs marked as blocking the beta release
[03:43] <carlos> https://bugzilla.warthogs.hbd.com/bugzilla/showdependencygraph.cgi?id=1965
[03:43] <carlos> kiko: URL?
[03:43] <kiko> debonzi?
[03:43] <carlos> or is not yet ready?
[03:43] <debonzi> kiko, 
[03:44] <kiko> IIRC it's nor PQM-merged, is it debonzi?>
[03:46] <debonzi> kiko, yes.. the portlet is in rocketfuel
[03:46] <kiko> neat
[03:46] <kiko> carlos, look at any source package in soyuz (with translations and product/project association, which means with a full DB I believe)
[03:46] <SteveA> carlos: I'll get you information on how to do i18n on launchpad later today
[03:46] <SteveA> then you can start using rosetta to translate rosetta
[03:46] <carlos> SteveA: perfect
[03:46] <carlos> thanks
[03:46] <BradB> SteveA: i have one other thing to mention about df malone and mdz, when you're ready
[03:47] <carlos> kiko: ok, I will take a look later today
[03:47] <kiko> neat
[03:47] <SteveA> BradB: yep
[03:47] <BradB> SteveA: yesterday mark wanted to walk mdz through malone, but unfortunately the server wasn't up and running quite in time.
[03:48] <BradB> SteveA: it will be really valuable for mdz to see it, because we want it to be used for source package bugs asap.
[03:48] <BradB> SteveA: so if it can be arranged to have someone else walk him through it, that would be good.
[03:48] <SteveA> can you walk him through it?
[03:48] <BradB> sure
[03:48] <SteveA> ok, please arrange this with mdz
[03:48] <SteveA> then, mdz can make the call as to if they can start using it
[03:48] <carlos> BradB, SteveA: When will we start using malone for launchpad's bugs?
[03:48] <stub> Our first audience is ourselves. Warthogs and ubuntu stuff follows.
[03:49] <SteveA> you'll need to make sure mdz understands what data we're keeping and what we're not
[03:49] <BradB> SteveA: sounds good
[03:49] <kiko> I was going to say what stub said, we should move to malone before mdz does
[03:49] <BradB> carlos: now, i think
[03:49] <carlos> ol
[03:49] <carlos> ok
[03:49] <carlos> :-)
[03:49] <BradB> carlos: and if anything doesn't work correctly, we'll just have to fix it quickly so that it can be. :)
[03:50] <carlos> :-P
[03:50] <BradB> stub, kiko, SteveA: I have to admit, we may want to "harden" Malone a bit more before we go too crazy demoing it elsewhere, but Mark was ready to jump in last night. :P
[03:50] <stub> regarding that.... we want to avoid having to rollback a dogfood update unless there is a really fatal problem.
[03:51] <carlos> how are we going to handle the logins? we (rosetta) are having problems with the current authentication schema:
[03:51] <carlos> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2076
[03:52] <SteveA> let's hear from launchpad-brazil about soyuz dogfooding
[03:53] <kiko> that's us
[03:54] <kiko> we're currently approaching the status where everything we touch is surrounded by an SEP field
[03:54] <SteveA> in non-douglass-adams-english ?
[03:54] <kiko> Someone Else's Problem 
[03:55] <kiko> from now on it's going to be a lot harder to move forward with soyuz without some guidance
[03:55] <kiko> we have one last thing to improve which is significant, which is the per-developer package listing
[03:56] <kiko> we want to include as much of packages.qa's features there without making blood come out of users' eyes
[03:56] <kiko> but then there's mainly polish to be done because we are halted on main bits that are not in our hands currently
[03:57] <kiko> buildbot and katie's successor are probably the main blockers (and the db schema changes that come with them)
[03:57] <kiko> we've started picking up the malone/rosetta integration bits because they were bothering us
[03:58] <kiko> but buildbot and katie2 (what's her name?) are a lot more involved and require some Decisions From Above
[04:00] <kiko> I believe lucille, buildbot and katie2 integration block dogfooding, to be honest, because if you can't track package uploads, approvals and builds, then, well..
[04:01] <kiko> have I said enough already? I can go on for a bit more if people like (but you know that already <wink>)
[04:02] <SteveA> BradB, stub: sabdfl suggests to start with a clean-ish database
[04:02] <kiko> ta
[04:02] <stub> So these decisions from above - is this blocked until Mark can look at the issue, or do you just need feedback or work from the buildbot and katie2 people?
[04:03] <stub> cleanish... technical term?
[04:03] <kiko> there's some design work and "interfaces" that need to be done. I think it requires mark-love
[04:07] <SteveA> I'll be calling Mark in 30 minutes.
[04:07] <SteveA> Are there any issues that need mark's input that I can ask him about?
[04:07] <kiko> be sure to communicate our quandary with him
[04:08] <kiko> or perhaps tell him I'd like to talk to him today as well
[04:08] <BradB> SteveA: when he wants to have warthogs using malone
[04:08] <SteveA> whats' the quandry (I was talking with mark on the phone)
[04:09] <kiko> SteveA, do you have scrollback?
[04:09] <BradB> SteveA: it'd be nice if we could just have a few warthogs using it at first.
[04:09] <SteveA> kiko: yep.  can you give me the 10 word summary?
[04:09] <kiko> soyuz is stuck?
[04:10] <SteveA> aren't you going to get feedback from warthogs when they start using it?
[04:10] <kiko> I don't believe this has to do with end-users -- see my comments.
[04:11] <kiko> we're blocked by platform integration issues
[04:15] <SteveA> BradB: mark will walk mdz though it tonight, 8UCT.  can you be there?
[04:15] <BradB> SteveA: yep
[04:15] <SteveA> and be sure malone is shiny and working first
[04:15] <BradB> ok
[04:16] <SteveA> kiko: mark will give you a call
[04:17] <kiko> SteveA, thanks, I'll be here the whole day just waiting
[04:24] <BradB> stub: Are you going to add me (and whomever else) to the users in launchpad_dogfood, or should I just add myself?
[04:25] <stub> I'm not actually sure of the current way of creating users - last time it was a script in lib/rosetta/scripts
[04:25] <BradB> daf, carlos: how do i add myself as a user?
[04:26] <SteveA> kiko: I expect he
[04:26] <SteveA> kiko: I expect mark will call you nowish
[04:26] <carlos> BradB: we have a script at lib/canonical/rosetta/scripts/createuser.py
[04:26] <carlos> BradB: not sure if it will work after all database changes, please tell me if you have any problem
[04:26] <carlos> it has a --help argument
[04:26] <carlos> BradB: because we were the firsts :-P
[04:26] <SteveA> can we move it somewhere better?
[04:27] <carlos> sure
[04:27] <SteveA> stub:  how's the authenticated bugzilla thing going?
[04:27] <carlos> BradB: if you don't give it a password it will generate one for you
[04:27] <carlos> SteveA: any suggestion about where should we move this kind of tools?
[04:27] <stub> SteveA: Havn't looked at that. Got bogged down in crud today.
[04:27] <kiko> nick kiko-fud
[04:28] <SteveA> BradB, stub: when I can start filing new bugs for launchpad in malone?
[04:30] <BradB> SteveA: I need to take a look through it now (which I'm in the middle of doing) to see what needs fixing.
[04:30] <stub> I suspect it is ready to go as soon as I clear out the database
[04:30] <BradB> stub: As I mentioned on the ML, I think there's no way in heck we'll be able to do daily updates of the dogfood server though. :)
[04:30] <BradB> (just a random thought about qa on mawson)
[04:30] <SteveA> when it is ready, send an email to the launchpad list saying that all new launchpad bugs are to be filed in malone, and give some URLs to use.
[04:31] <BradB> sure, i'll do that
[04:39] <stub> Hmm... If I pull a copy of the production database onto dogfood it should be fairly nicely initialized
[04:39] <BradB> SteveA: the thing to be noted is that using Malone to handle Launchpad bugs is a pretty ugly hack
[04:39] <BradB> stub: Same schema?
[04:39] <stub> After I've run the patches it will be
[04:40] <BradB> stub: as long as no data migration is needed, it should be straightforward, I guess
[04:40] <BradB> SteveA: e.g. are rosetta, malone, and soyuz "source packages"? :)
[04:40] <stub> BradB: Not a problem - its exactly the same as upgrading the production system
[04:43] <SteveA> BradB: yep -- unreleased source packages
[04:48] <kiko> thanks SteveA
[04:48] <kiko> so BradB
[04:48] <kiko> mark suggested we get some help on your side testing and polishing malone
[04:48] <kiko> would you be interested in an extra pair or two of hands?
[04:49] <BradB> kiko: sure
[04:49] <kiko> in the afternoon, let's talk a bit then about what you feel could be valuable
[04:49] <kiko> apart from random using and code reviewing
[04:49] <BradB> ok
[04:50] <kiko> Kinnison?
[04:50] <ddaa> spiv_: duh, the strports patch breaks...
[04:51] <BradB> dogfood going down momentarily...
[04:51] <kiko> neat.
[04:52] <stub> I've got a database to drop in place of launchpad_dogfood - can I bounce it, or do you need to Brad?
[04:52] <spiv_> ddaa: Hmm :/
[04:53] <ddaa> for some reason the slave does not seem to be able to shake hands with the botmaster when I use a strport to create the slavePort service too. I'm testing that.
[04:53] <BradB> elmo: IOError: [Errno 13]  Permission denied: '/var/tmp/launchpad_mailqueue/tmp/1098888772.20818.rosetta' when trying to send mail from dogfood
[04:55] <stub> BradB: That queue is configured in package-includes/mail-configure-normal.zcml if the default won't work on mawson
[04:55] <ddaa> oops
[04:55] <ddaa> spiv_: nm, thanks for listening.
[04:55] <BradB> stub: the only data we have to keep is https://launchpad.ubuntu.com/doap/projects/canonical and the three projects listed therein
[04:56] <ddaa> programmers editors should _not_ have a copy-paste feature!
[04:56] <BradB> if you blow it away, it'd be nice if you could readd it (which I've already done once) so that i can continue to make sure that Malone doesn't suck by the time Mark demos it
[04:57] <BradB> what's with screen not understanding my backspace key, sheesh
[04:57] <spiv_> ddaa: No problem :)
[04:58] <stub> BradB: Don't suppose you have the SQL lying around :-)
[04:58] <BradB> nah, I just save as'd and copied and pasted
[04:59] <BradB> 4 pages
[05:02] <BradB> shit, how do i make a mail dir folder again?
[05:02] <BradB> i thought there was a makemaildir command or something
[05:03] <BradB> mkdir -p q/cur q/old q/new?
[05:04] <carlos> BradB: if it's a maildir controlled by postfix, just send an email and it will create it as it should be
[05:04] <BradB> i have no idea how to do that. zope won't start because foo isn't a maildir folder
[05:05] <BradB> i don't know how to send a mail from the cmd line and say "use foo as the queue"
[05:05] <SteveA> mgedmin is on #zope3-dev
[05:05] <BradB> there's a command called makemaildir, but mawson doesn't have it
[05:05] <SteveA> maybe ask on there
[05:06] <SteveA> so is alga
[05:06] <carlos> BradB: then create cur, new, tmp inside the directory, it should be enough...
[05:06] <BradB> ah, tmp, not old
[05:06] <carlos> SteveA: is the meeting over then?
[05:06] <stub> BradB: Why does zope want a maildir folder? It just just wants somewhere it can create a queue directory
[05:06] <SteveA> carlos: yes I guess so :-)
[05:07] <SteveA> sorry, it was over a while ago
[05:07] <carlos> ok, thanks :-)
[05:07] <SteveA> I forgot to say
[05:07] <BradB> carlos: thanks, that worked
[05:08] <dilys> Merge to thelove@canonical.com/bazaar-debian--debian--1.0: adjust for the name change tla -> baz. dont merge this changeset to a tla branch (patch-1)
[05:08] <kiko> go lifeless go
[05:08] <BradB> stub: dunno dude, but that's what the error message said queuePath needs to be
[05:09] <stub> Wierd - If I saw that when I was putting it together, I've totally forgotten about it :-/
[05:09] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: adjust for the name change tla -> baz by making the libfoo includes dir name agnostic. dont merge this changeset to a tla branch without removing the name change aspect (patch-1)
[05:11] <carlos> dudes, I thought "thelove" was just a joke X-)
[05:11] <stub> :-)
[05:11] <dilys> Merge to rocketfuel@canonical.com/buildbot--devel--0: use strports for more flexible configuration (patch-65)
[05:12] <ddaa> ha... at last.
[05:12] <ddaa> spiv_: you are free to merge into rf again.
[05:19] <BradB> kiko: It's 11:18 where you are right now, right? Perhaps we could do the Malone discussion at 13:30.
[05:19] <kiko> I need about 2h, and it's now 12:18 here 
[05:19] <kiko> sounds okay
[05:19] <BradB> ok, cool
[05:22] <stub> BradB: Can I try swapping the database now? I need to shutdown the df server to do it and don't know if I can or the preferred way
[05:23] <Kinnison> I've now got a shell script for starting the librarian
[05:23] <BradB> stub: As long as you're confident that the data is enough to bootstrap df (and you'll be able to readd the canonical project), then yes, go for it.
[05:23] <cprov> Kinnison: fantastic ! can u send me 
[05:24] <Kinnison> cprov: can what where who?
[05:24] <stub> And how do I do it?
[05:24] <kiko> Kinnison, the shell script?
[05:24] <cprov> Kinnison: script to run/start librarian :P
[05:24] <BradB> load the db? no idea, you'd know more than me about how to do that, i would have thought.
[05:24] <BradB> i can shutdown the server though right now, if you're ready
[05:24] <Kinnison> /srv/launchpad.ubuntu.com/librarian/run-librarian.sh on mawson :-)
[05:24] <stub> No - stop and start the server :-)
[05:25] <BradB> stub: ready for me to stop it then?
[05:25] <stub> Yup
[05:25] <BradB> stub: stopped. go nuts.
[05:27] <stub> BradB: Ok - that should be fine.
[05:27] <stub> I've still got the old db btw if it isn't suitable for demo with the prod data loaded
[05:28] <Kinnison> Whoever prods about with the db should make damned sure that the librarian and the db are kept in sync
[05:28] <BradB> https://launchpad.ubuntu.com/malone/bugs/1 hah hah hah
[05:28] <BradB> stub: where the /heck/ did that bug come from? :)
[05:29] <stub> An old joke of Marks from before I was on board... I'd forgotten about it. That will keep Mark happy :-)
[05:29] <BradB> heheh
[05:38] <carlos> BradB: What should we do to get our account in launchad?
[05:38] <carlos> O:-)
[05:38] <BradB> carlos: It should already be in there.
[05:38] <carlos> BradB: the website one?
[05:39] <BradB> yes
[05:39] <carlos> because my account from the sample data fails
[05:39] <carlos> ok
[05:39] <BradB> This is Real Data.
[05:39] <stub> Kinnison: You will need to email the admins about getting the Librarian data baked up
[05:39] <Kinnison> stub: I assume you're going to be doing dumps of the db to be backed up?
[05:39] <stub> Yup - just doing the cron jobs now
[05:39] <Kinnison> stub: along with that dump; put a tar of the librarian root?
[05:40] <Kinnison> (although that's 16 gigs a pop)
[05:40] <BradB> stub: when do we get all the source packages and products imported?
[05:40] <BradB> stub: I would think that would be really, really nice for when mark demoes it to mdz
[05:40] <carlos> BradB: you forgot to import languages.sql
[05:41] <stub> When someone runs the magic script? That is Katie isn't it?
[05:41] <BradB> carlos: I didn't forget anything, that's stub's job. :)
[05:41] <stub> carlos: that would be me - I mirrored the production database.
[05:41] <carlos> :-P
[05:41] <carlos> stub: could you do it, please?
[05:41] <stub> Which obviously doesn't have the languages installed...
[05:41] <carlos> Rosetta is useless without it
[05:42] <BradB> elmo, Kinnison: are you guys the ones to ask for getting packages and products imported into dogfood?
[05:42] <Kinnison> it needs gina IIRC
[05:42] <stub> carlos: done
[05:43] <Kinnison> Which needs someone to tell me that gina can do the new schema; whereupon I'll commit my build merges
[05:43] <carlos> stub: thanks
[05:43] <BradB> cprov: ^?
[05:45] <BradB> I'll manually add source packages for malone, rosetta and soyuz right now, so that we can report bugs against those systems.
[05:46] <Kinnison> Do we need to ask you to create users for us?
[05:47] <BradB> Kinnison: yes, where you == stub.
[05:47] <Kinnison> BradB: cunning
[05:47] <BradB> :P
[05:47] <Kinnison> stub: Can I have a user in dogfood please?
[05:48] <stub> Anyone with access to the launchpad user should be able to run rosetta/scripts/createuser.py
[05:48] <BradB> Kinnison: you should already have one
[05:48] <Kinnison> oh right
[05:48] <Kinnison> So I do
[05:48] <Kinnison> I wonder what my password is
[05:48] <stub> It is a mirror of the production database  - there are accounts there, but I don't know if the passwords are sane
[05:48] <BradB> Kinnison: yep, you're already in there, i can see
[05:49] <Kinnison> yay; the forgotten password page doesn't work though
[05:50] <BradB> Kinnison: use the real one for now then
[05:50] <BradB> (real fp page, that is)
[05:50] <BradB> er, no, that won't work
[05:50] <Kinnison> eh?
[05:50] <BradB> because fp resets your pw
[05:51] <BradB> Kinnison: off the ul.org site, i meant
[05:51] <BradB> but anyway, it won't work :)
[05:52] <BradB> heh
[05:53] <stub> Our first bit of successful dogfooding - well done :-)
[05:54] <BradB> stub: What's the correct way to add a source package called "malone" to LP? I'm not sure what namespaces (e.g. distro) to create, etc. to make that appear in the system in a sane way.
[05:54] <Kinnison> w00p w00p; logged in :-)
[05:54] <BradB> A distro called Launchpad maybe?
[05:55] <stub> You need a soyuz person me thinks
[05:55] <BradB> cprov: ping
[05:55] <BradB> kiko-fud: ping
[05:55] <Kinnison> the CSS is so fucked
[05:56] <Kinnison> I have bits of text changing colour as I move my mouse around
[05:56] <BradB> cool
[05:57] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: s/tla/NAME in the obvious parts of the help, defining NAME as baz (patch-2)
[05:58] <stub> whip it good
[06:01] <BradB> darn, I really need at least a couple source packages and a couple products/product releases in LP before I can do anything useful. 
[06:03] <stub> BradB: distro is nullable, so I suspect you can just create a row in the Sourcepackage table for it with a corresponding entry in the SourcepackageName table.
[06:14] <BradB> spiv_: ping
[06:14] <spiv_> Pong.
[06:15] <BradB> er, wait, maybe not...
[06:15] <BradB> here's the problem:
[06:15] <stub> Kinnison: I'm just emailing admins@ about bakups - have you done librarian, or can you give me a directory name and I'll add it to the same email?
[06:15] <BradB> i need products and product releases in malone, so that mark can usefully demo features to mdz that require those
[06:16] <Kinnison> stub: /srv/launchpad.ubuntu.com/librarian/ is where it'll be
[06:16] <BradB> spiv_: i was going to ask you to add products and product releases for "malone", "soyuz", and "rosetta", but that probably doesn't make sense.
[06:16] <Kinnison> If we're done fiddling the db then I'll start the librarian running
[06:16] <stub> Kinnison: We should backup the whole thing? Or is there a data directory?
[06:16] <BradB> since having them as sp's should be enough...but in any case, we need some products/product releases in there asap, because the demo's in 2h 45m, and I've still got to test with some realish data.
[06:16] <spiv_> Hmm.
[06:17] <stub> I'm done fiddling - unless Brad has a need to dump the database?
[06:17] <Kinnison> stub: the whole thing *is* the data dir :-)
[06:17] <stub> oic
[06:17] <stub> :-)
[06:17] <Kinnison> stub: the metadata is stored in the db :-)
[06:17] <stub> I assumed the source code was in there, but of course that is in lib/canonical/librarian :-)
[06:18] <BradB> spiv_: where do product/product releases come from?
[06:18] <BradB> i.e. from where would that data be imported, or using which scripts?
[06:19] <spiv_> The arch guys have set up some of that for their production importd.
[06:20] <spiv_> I'll see if there's any useful production data we can snarf for this...
[06:20] <BradB> spiv_: can you arrange to have that imported into launchpad_dogfood on mawson asap, if possible?
[06:21] <spiv_> The production db has some products, but no product releases.
[06:21] <Kinnison> So I can start the librarian then?
[06:22] <stub> Kinnison: Yup
[06:22] <BradB> spiv_: can i leave it to you to somehow get sane products and product releases in there in the next 30 mins or so?
[06:22] <spiv_> Ok.
[06:23] <BradB> thanks
[06:23] <BradB> Kinnison: what does the librarian do? i know it has something to do with serving up packages, but i'm not totally clear (does it have anything to do with getting sp's and spr's into lp_df by any chance?)
[06:24] <Kinnison> it's running now :-)
[06:24] <stub> BradB: It stores all our binaries basically
[06:25] <BradB> stub: not spr's?
[06:25] <stub> BradB: Malone will want to store email attachments in there.
[06:25] <stub> spr?
[06:26] <BradB> source package release
[06:27] <stub> tarballs, iso images, whatever. All binaries and documents that don't need to live in the database.
[06:28] <Kinnison> basically anything where you would say "Hmm, I can't store that much data in a column" you'd use the librarian
[06:28] <stub> You just say 'store this file and give me an id' or 'give me the url for this file' (well.. that second is a todo...). 
[06:28] <BradB> ah, that's what i thought
[06:28] <Kinnison> We're fairly close to being able to do the url thing
[06:28] <BradB> so it makes it easy to go from sqlobjects to the files related to them, presumably.
[06:28] <Kinnison> So gina stores the debs, tarballs etc in the librarian and lucille pulls them out again for example
[06:29] <BradB> woo
[06:29] <Kinnison> Well, we can go from sqlobjects to an ID; I'll try and finish the bits that will allow us to go from a LibraryFileAlias instance to a URL to a file or to the file itself
[06:30] <BradB> sounds cool
[06:31] <Kinnison> But that is not even on my "next week's work" radar currently
[06:31] <Kinnison> although if I get bored with lucille in the short-term I might take a knuthian and do it
[06:32] <stub> ok - bed time for me. Am I needed for anything else?
[06:32] <Kinnison> not afaict
[06:32] <ddaa> lifeless: job names _cannot_ contain spaces.
[06:32] <Kinnison> stub: what timezone are you in?
[06:32] <carlos> spiv_: can we use "... AND EXISTS (nested query)" inside the select method of a sqlobject?
[06:32] <BradB> stub: looks good, thanks
[06:32] <BradB> carlos: it's just a WHERE clause...
[06:33] <ddaa> lifeless: your popen-based spawns will just blow up when given a name with spaces.
[06:33] <carlos> BradB: I suppose that's a yes :-P
[06:33] <carlos> thanks
[06:33] <BradB> no prob
[06:33] <ddaa> exceptions.RuntimeError: cvs -d /home/david/canonical/launchpad/botmaster/slave/buildbot-jobs/vte HEAD import.job/vte@arch.ubuntu.com/vte--MAIN--0/cvs_temp_repo init failed (256)
[06:33] <ddaa> 	Unknown command: `HEAD'
[06:42] <BradB> anyone have kiko's phone number?
[06:44] <ddaa> These commands are so totally unsafe...
[06:44] <BradB> ddaa: The commands are safe, as long as the programmers wrote safe code.
[06:45] <lifeless> ddaa: hah. oops.
[06:45] <ddaa> You can be pretty sure that 95% of the time, people using these commands will not do the quoting correctly.
[06:46] <ddaa> And 5% of safe code is generous imho.
[06:46] <ddaa> lifeless: I'll fix it.
[06:46] <ddaa> Not sure how, but I'll do it.
[06:46] <BradB> this is why Python really needs a taint mode. :)
[06:46] <lifeless> the web page ui is freaking you out that much ?
[06:46] <ddaa> That's why people using these functions needs to be beaten on the public place!
[06:47] <BradB> spiv_: how's things coming with the product imports?
[06:47] <ddaa> lifeless: yes, it's freaking me out. With wrapping I can fit at least 12 jobs in a screen width. Without I can fit something like 4 jobs.
[06:48] <ddaa> It's _really_ annoying.
[06:48] <lifeless> why do you need jobs on the screen at once ?
[06:48] <ddaa> to monitor progress.
[06:48] <spiv_> BradB: There's now a release each for Soyuz, Rosetta and Malone in there.
[06:48] <lifeless> 4 jobs at once will thrash your poor little laptop anyway.
[06:49] <ddaa> I'm on a desktop.
[06:49] <lifeless> buildbot won't run more than 10 at once
[06:49] <ddaa> And the jobs i am running are not always contiguous in the table.
[06:49] <lifeless> just use the pick-list.
[06:49] <BradB> spiv_: right on, thanks dude
[06:49] <lifeless> ctrl-click and select the ones you want
[06:49] <ddaa> ?
[06:49] <lifeless> also, the stats page is what I use, which is more compact still
[06:50] <lifeless> ddaa: go to /
[06:50] <lifeless> there is a link to 'select jobs'
[06:50] <lifeless> should help you
[06:50] <lifeless> I'm not completly tracking though, so I'm going crash.
[06:51] <ddaa> Anyway, thatNo, there is not.
[06:51] <ddaa> Bah.
[06:51] <lifeless> right now though, the UI should be ____bottom______ of your list.
[06:51] <ddaa> Anyway, that bug needs fixing, doesn't it?
[06:51] <lifeless> add it to bugzilla.
[06:52] <lifeless> short term, trap them in the job loading code in canonical.arch.
[06:52] <lifeless> because that would be bad to be bitten by.
[06:53] <lifeless> and yes, we'll want to fix it eventually. But we have to triage: not all bugs are equal.
[06:53] <lifeless> the hangs, for instance, are /much more/ severe because we can't work around them, cannot filter them, cannot deal with them.
[06:53] <ddaa> Okay. So you want to s/ /\ / in job names or something?
[06:54] <ddaa> s/ /-/
[06:54] <ddaa> ?
[06:54] <lifeless> that would be fine
[06:54] <ddaa> first or second?
[06:54] <ddaa> second...
[06:54] <ddaa> less hacky
[06:54] <ddaa> less evil
[06:54] <lifeless> or s/[ ;/\\${}()] /_/
[06:55] <ddaa> add in [] *?
[06:55] <lifeless> yeah, you see where I'm going
[06:55] <ddaa> and '"
[06:55] <ddaa> okay
[06:55] <lifeless> night. my brain is toast
[06:55] <ddaa> mhhhhhh
[07:07] <BradB> elmo: the VH'ing is screwed up on mawson:
[07:07] <BradB> https://launchpad.ubuntu.com/malone/bugs/1
[07:07] <BradB> hover over "bugs" in the breadcrumbs
[07:07] <BradB> notice the ++vh++ in the link
[07:11] <SteveA> that's normal
[07:11] <SteveA> the breadcrumbs are broken, and shouldn't be in launchpad at the moment
[07:12] <SteveA> the virtual hosting is working fine, no need to bother elmo
[07:12] <SteveA> the breadcrumbs are implemented in a way that doesn't use the proper zope3 api to be aware of virtual hosting
[07:13] <SteveA> the underlying problem is zope3's attachment to "location" in the object graph, and linking this to URLs
[07:13] <SteveA> this part of zope3 is rather bogus
[07:14] <SteveA> I'm campaigning for it to be changed in zope3, but supporting canonical stuff is nearer the top of my todo list
[07:21] <BradB> Kinnison: if i restart DF does that affect you in any way?
[07:22] <BradB> SteveA: maybe it's the "and linking this to URL's part" that smells.
[07:22] <BradB> i would have thought that anything that knows how to make a URL from a location should know if I'm a VH.
[07:22] <SteveA> the point is we're not using locations
[07:23] <SteveA> locations are supposed to be optional in zope3
[07:23] <SteveA> normal python code doesn't use locations
[07:23] <BradB> ah
[07:23] <SteveA> just the zope3 pseudo-content-management system
[07:23] <SteveA> that is __name__ and __parent__
[07:23] <Kinnison> BradB: If you restart the launchpad instance the librarian is fine
[07:24] <Kinnison> BradB: if you want to fuck with the db then you may have to kill/restart the librarian
[07:24] <SteveA> I want to have a proper think about this, and implement the right solution for dealing with virtual hosting.  I can't do this until I get back from vacation.
[07:24] <SteveA> meanwhile, either turn breadcrumbs off, or hack it into working somehow
[07:24] <SteveA> but, don't embark on major architecture (like making all our stuff "locations" in the zope3 sense)
[07:24] <BradB> SteveA: so I make myself placeful by implementing IContained?
[07:24] <SteveA> no
[07:24] <SteveA> please don't do that
[07:25] <BradB> no, I wouldn't, but I'm curious
[07:25] <SteveA> that's biting off the zope3 locations crack
[07:25] <SteveA> and I don't want us to go there
[07:25] <BradB> I just meant in "normal" Zope 3 development, would that be how I'd do it?
[07:25] <SteveA> kind of
[07:25] <SteveA> that's part of it
[07:25] <SteveA> using zope3 containers for everything would sort it out for you
[07:25] <BradB> but we won't be doing that :P
[07:26] <BradB> ok, so maybe this won't suck when you get back from sicily
[07:26] <SteveA> yeah.  I will be bringing my laptop and archives on vacation
[07:26] <SteveA> I don't promise to do anything with them, though
[07:27] <SteveA> the virtual hosting / urls / etc. stuff touches more than just breadcrumbs
[07:27] <SteveA> so I do want to get it right.
[07:27] <SteveA> but, I think I might end up checking out my thoughts with Jim, and possibly tweaking parts of zope3
[07:28] <SteveA> there's already one relevent tweak in the pipeline, to make our use of suburls and traversal cleaner.
[07:28] <SteveA> but, i need to talk to jim further about it
[07:28] <SteveA> (we discussed it at length in vienna)
[07:29] <BradB> oh shit
[07:29] <BradB> i hope this:
[07:29] <BradB> gpg: no default secret key: bad passphrase
[07:29] <BradB> gpg: [stdin] : clearsign failed: bad passphrase
[07:29] <BradB> Null message body; hope that's ok
[07:29] <SteveA> when we've got dogfood well and truely going, I'll see if mark will give me a few days to get some zope3 stuff done that will make our future easily
[07:29] <BradB> doesn't start a pqm loop
[07:29] <BradB> SteveA: cool
[07:29] <SteveA> I guess if gpg failed, pqm won't do anything at all
[07:29] <spiv_> BradB: No, pqm will just reject it.
[07:29] <BradB> good
[07:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed the statistics update script. It's not finished, See bug #1975 for more info (patch-705)
[07:30] <BradB> PQMException! w00t.
[07:30] <SteveA> spiv_: ping ping
[07:30] <spiv_> pong pong.
[07:30] <SteveA> hi
[07:30] <SteveA> what are you up to at the moment?
[07:30] <SteveA> you missed the meeting today
[07:31] <Kinnison> c'ya
[07:32] <SteveA> spiv_: look in launchpad/sourcecode/zope/src/ZConfig/doc for ZConfig docs
[07:32] <SteveA> there's a comprehensive manual on using and extending it
[07:32] <spiv_> I'm about to sink my teeth into some DOAP work, now that the arch guys don't have anything else they need from me.
[07:33] <SteveA> I'd like you to make it so we can specify the database to use in launchpad.conf 
[07:33] <spiv_> Yeah, that sounds like a good idea.
[07:33] <spiv_> I'll take a look, thanks.
[07:34] <SteveA> ok, please do it soon
[07:34] <SteveA> I don't want random configuration settings to appear in zcml or random python files.
[07:34] <SteveA> pragmatically, we need to do this now for buildbot
[07:34] <SteveA> but it should not stay that way.
[07:35] <SteveA> I'd also like you to make launchpad look for launchpad.conf.in before launchpad.conf
[07:35] <SteveA> so, we can provide a default launchpad.conf.in, but it can be overridden with launchpad.conf
[07:36] <spiv_> Right.  Buildbot is probably the worst-case here; the configuration stuff it already has is ugly and requires a fair bit of surgery to the code to fix.
[07:38] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: fixed adding bugtrackers (patch-706)
[07:38] <BradB> SteveA: by the way, i want to announce launchpad-dogfood today. could you clarify who are the intended users right now, who should be using the dogfood app, and what for?
[07:39] <SteveA> spiv_: file bugs please!  (perhaps even in malone...)
[07:39] <SteveA> the launchpad team should be using it for bug tracking.
[07:39] <SteveA> other users are to be decided, after you and mark and mdz get together tonight
[07:40] <spiv_> Ok, I'll start poking bugs into the dogfood malone :)
[07:41] <BradB> SteveA: he'll be on IRC, presumably?
[07:41] <SteveA> yep
[07:41] <BradB> speaking of which, i'm supposed to be discussing Malone with kiko 10 minutes ago :)
[07:41] <SteveA> at whatever time I mentioned earlier
[07:42] <dilys> Bug 2087 resolved: initZopeless patch
[07:42] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2087
[07:42] <SteveA> BradB: will spiv_ be able to file the "use zconfig for launchpad database conf" bug in malone? 
[07:42] <BradB> SteveA: not yet, there's no launchpad source package
[07:43] <BradB> he could go in and add one manually in the absense of the soyuz guys, like i did earlier
[08:13] <BradB> SteveA: i can patch plone (CC) now...i was just taking a few minutes now to figure out what i'm doing by applying that patch
[08:14] <SteveA> BradB: hold off on that please
[08:14] <BradB> SteveA: is this an attempt to try and force ssl all the time?
[08:14] <BradB> ok
[08:15] <SteveA> I'm sorting out cacheing properly at the moment
[08:15] <BradB> oh, ok
[08:15] <SteveA> elmo thinks it is crackful to run ssl for all authenticated users
[08:15] <SteveA> we'll burn gentoo up ;-)
[08:15] <kiko-fud> BradB, yes?
[08:15] <BradB> kiko-fud: two things:
[08:16] <BradB> threeish, actually
[08:16] <BradB> 1. we need packaged imported into launchpad-dogfood asap (demo in 45 mins)
[08:16] <BradB> s,packaged,packages,
[08:17] <BradB> 2. I added a package for "malone" without a distro right now. Not sure if you guys have a more sane way to do this, but we need packages in the right places called "malone", "rosetta", and "soyuz"
[08:17] <kiko-fud> source packages? or products?
[08:17] <BradB> 3. I thought we were going to meet 45 minutes ago to discuss Malone. :P
[08:17] <BradB> kiko-fud: source packages...if you can do products too, sure, but i thought that was spiv_ 
[08:17] <kiko-fud> I took too long, we're buying some SCSI hard drives but it's challenging to get right.
[08:18] <kiko-fud> BradB, well, hmmmm. you've got a minor problem there
[08:18] <kiko-fud> our "mass package imports" are done today via Gina
[08:18] <BradB> does gina work with the new schema?
[08:18] <kiko-fud> that's with Kinnison, he said that *was* happenning
[08:19] <BradB> kiko-fud: he was blocked by you guys
[08:19] <BradB> wanting to know if gina worked with the new schema
[08:19] <cprov> BradB: pong
[08:20] <kiko-fud> Kinnison was blocked by *us*?
[08:22] <BradB> [11:43]  	<Kinnison>	Which needs someone to tell me that gina can do the new schema; whereupon I'll commit my build merges
[08:23] <BradB> we've got 37 minutes :)
[08:23] <BradB> er, maybe 1h 37m
[08:23] <kiko-fud> oh, I see
[08:23] <kiko-fud> well, we were until now blocked on gina 
[08:23] <kiko-fud> however cprov now has access to is
[08:24] <kiko-fud> can someone fill me in on what "new schema" means?
[08:24] <Kinnison> I think there are some sourcepackage changes
[08:24] <Kinnison> gina barfs about not filling out a column which is NOT NULL
[08:24] <Kinnison> or something
[08:27] <kiko-fud> is that all? getting gina to run?
[08:27] <kiko-fud> stub?
[08:27] <kiko-fud> stub, are names with underscores forbidden?
[08:28] <kiko-fud> tla status -v ? :-P
[08:28] <kiko-fud> (it's a joke if you don't read me)
[08:28] <BradB> heh
[08:28] <kiko-fud> does anyone know why valid_name craps out on underscores?
[08:29] <BradB> kiko-fud: IF name IS NULL OR name SIMILAR TO \'^[a-z0-9] [a-z0-9\\+\\.\\-] +$\' THEN
[08:30] <kiko-fud> BradB, oh, I can read the regexp, I just want to know *why* it craps out on underscores.
[08:30] <BradB> if you're going to have tla tree-version, then tla tree-revision better Just Work
[08:30] <kiko-fud> I would assume underscores were valid names.
[08:31] <kiko-fud> cprov, how about we modify all underscores to hyphens?
[08:31] <BradB> kiko-fud: oh, you mean why the programmer disallowed them..
[08:31] <cprov> kiko-fud: ok
[08:31] <kiko-fud> BradB, no promises on that hard deadline, because honestly, gina takes a long time to run.
[08:31] <kiko-fud> oh ffs
[08:32] <kiko-fud> some dork took kiko
[08:32] <Kinnison> BradB: what *is* the tree revision though?
[08:32] <Kinnison> Oh yeah; gina is going to need multiple-architecture loving at some point
[08:33] <kiko-fud> yes, I know that part
[08:33] <BradB> Kinnison: good point, heh
[08:38] <kiko-fud> BradB, if you just want 3 packages, then you'll need to poison the sampledata
[08:38] <kiko-fud> what's it going to be?
[08:38] <BradB> kiko-fud: we don't use sample data
[08:38] <kiko-fud> well, "sample data", does that help?
[08:39] <kiko-fud> given that malone, soyuz and rosetta don't have debian packages and therefore don't live in katie
[08:39] <BradB> kiko-fud: there's no poisoning, i meant that i needed someone who knows soyuz do go in there by hand and add them in a sane way (e.g. possibly creating a distro for them, etc.)
[08:40] <kiko-fud> Oh.
[08:40] <BradB> "by hand" i.e. via the UI
[08:40] <kiko-fud> you can't create packages using the soyuz interface.
[08:41] <kiko-fud> it's not meant to be used that way
[08:41] <BradB> oh, hm
[08:41] <kiko-fud> packages go into the system via a complicated upload process that only Kinnison understands <wink>
[08:41] <BradB> then i guess "by hand" means via SQL
[08:41] <kiko-fud> that can be done
[08:41] <kiko-fud> the fact that cprov left must mean that debonzi is our only hope :)
[08:41] <kiko-fud> debonzi?
[08:41] <BradB> heh
[08:41] <kiko-fud> so you want help there so we can report bugs on these packages, is that is?
[08:41] <kiko-fud> there's some information we need to guess
[08:41] <kiko-fud> such as the source package release version
[08:41] <kiko-fud> and the related binary packages
[08:41] <kiko-fud> maintainer
[08:41] <kiko-fud> etc :)
[08:42] <BradB> wow, tla logs seems badly broken
[08:42] <BradB> tla logs -h says:
[08:42] <BradB> usage: tla logs [options]  [[archive] /version ...] 
[08:42] <BradB> but somehow:
[08:42] <BradB> bradb@oxygen:~/launchpad/lp$ tla logs -A rocketfuel@canonical.com launchpad--devel--0 | tail -1
[08:42] <BradB> patch-704
[08:43] <BradB> madness. pure madness.
[08:43] <kiko-fud> it just lists the patch #?
[08:43] <BradB> yeah, that's what i wanted though
[08:43] <BradB> can't find that out on mawson though
[08:43] <kiko-fud> who did the checkout?
[08:44] <BradB> kiko-fud: i'm asking there "what's the last patch i've applied from the rocketfuel version blah--blah--0?"
[08:44] <BradB> kiko-fud: me, locally. you can't do checkouts on mawson.
[08:44] <BradB> i'm not interested in putting my private keys on mawson, anyway :)
[08:44] <BradB> but, i think i might have since star-merged, hmph
[08:44] <kiko-fud> so you rsynced your mirror and then checkout?
[08:45] <BradB> i did a build-config, tarballed and scp'd it up to mawson
[08:45] <kiko-fud> heh
[08:46] <BradB> kiko-fud: the last db patch is patch-3-12-0.sql
[08:46] <BradB> er, wait
[08:47] <BradB> yeah, that's the last one
[08:50] <kiko-fud> BradB, debonzi can probably do the DB hack for you
[08:50] <debonzi> hi BradB, can I help with something?
[08:50] <kiko-fud> BradB, explain what you need more or less in details
[08:51] <BradB> btw, the demo's at 20:00 UTC
[08:52] <BradB> debonzi: we need to be able to file bugs in malone for launchpad
[08:52] <BradB> debonzi: malone is written to cater to open source linux software i.e. packages, products, etc.
[08:53] <BradB> debonzi: so, for dogfooding purposes, we're going to shoehorn the ability to file lp bugs in malone by reported them against "unreleased packages" called "launchpad", "malone", "rosetta", and "soyuz" (unless there are better names)
[08:53] <BradB> i've already added malone, but I need you to:
[08:53] <BradB> 1. review that the way i added malone in the db is sane.
[08:53] <BradB> 2. add the other three
[08:53] <BradB> please
[08:54] <BradB> by "added malone" i mean "added malone as a sourcepackage"
[08:55] <kiko_bz> debonzi, do you have access to mawson?
[08:55] <debonzi> kiko_bz, I need to check
[08:56] <debonzi> BradB, right.. so what you need is add in sample data malone, soyuz, rosetta?
[08:56] <kiko_bz> right
[08:56] <debonzi> as sourcepackages
[08:57] <BradB> and launchpad
[08:57] <BradB> malone's already added, but i need you to verify that i did it in a sane way
[08:57] <debonzi> BradB, right.. I do that right now
[08:57] <BradB> thanks
[08:57] <debonzi> BradB, no problem
[08:58] <debonzi> kiko_bz, mawson ask me for password
[08:58] <BradB> elmo: ^
[08:58] <debonzi> kiko_bz, do I need it now?
[08:59] <BradB> yes please
[08:59] <elmo> he didn't have an account, fixed
[08:59] <BradB> thanks
[08:59] <kiko_bz> wondy
[09:00] <debonzi> yes, I am there
[09:00] <BradB> sudo -u launchpad -s
[09:00] <BradB> psql launchpad_dogfood
[09:00] <kiko_bz> or bash to make it easier
[09:00] <BradB> hm?
[09:00] <BradB> those are the commands debonzi needs :)
[09:01] <kiko_bz> I mean
[09:01] <kiko_bz> sudo -u launchpad bash
[09:01] <kiko_bz> gives him a launchpad shell
[09:01] <kiko_bz> from which he can pg_dump or psql as much as he likes
[09:01] <BradB> so does -s :)
[09:02] <kiko_bz> oh that's the -s
[09:02] <BradB> well, it gives him a $SHELL
[09:02] <kiko_bz> I was thinking it's one of those useless options
[09:02] <elmo> always either use -s or do 'sudo su - launchpad' instead
[09:02] <BradB> kiko_bz: heh heh
[09:03] <debonzi> BradB, did you add launchpad as a distribution?
[09:03] <BradB> elmo: by the way, can you make it so that i can sudo -u zope -s on gentoo without typing my p/w every time?
[09:03] <BradB> debonzi: nope
[09:03] <BradB> debonzi: i'm leaving that to you guys to best decide how it fits into soyuz.
[09:03] <kiko_bz> debonzi, but is launchpad a distro?
[09:04] <debonzi> BradB, no it isn't
[09:04] <debonzi> BradB, but it is there
[09:04] <BradB> somebody else added it then. the data in there is a dump of the prod db.
[09:05] <BradB> er, wait
[09:05] <debonzi> BradB, ok.. Ill leave like it for now
[09:05] <BradB> gargh, yeah that was me starting to do it through the UI before stub suggested i could mod the tables directly
[09:06] <BradB> the lp distro can be removed
[09:06] <debonzi> BradB, ok
[09:08] <elmo> BradB: meh
[09:08] <BradB> ok, maybe not
[09:16] <SteveA> elmo: please add "meh" to the ProjectGlossary
[09:23] <BradB> SteveA: heh heh
[09:24] <BradB> kiko_bz: when you're ready to talk about malone, i've got in mind something that would be really useful for you guys to work on
[09:31] <debonzi> BradB, this db is going to be used only for malone or this that should be also available for the other aplications?
[09:31] <debonzi> s/that/data
[09:34] <BradB> debonzi: it's a real, live launchpad instance, so for all apps
[09:34] <BradB> we're the only ones using it though
[09:34] <BradB> we == lp devs
[09:35] <debonzi> BradB, am asking because a sourcepackage lives in a distrorelease, so if this data should be used for soyuz for example the db should have a distro and distrorelease at least
[09:35] <cprov> Kinnison: ping
[09:36] <BradB> debonzi: the intent is that you guys (or cprov and kiko_bz...whoever's involved in that) will import all the "real" data we need to make soyuz look sane.
[09:36] <debonzi> BradB, at least for malone sourcepackages launchpad, soyuz, rosetta and malone should be available... do you have a way to check?
[09:37] <BradB> i'll check
[09:37] <debonzi> BradB, right..
[09:37] <Kinnison> cprov: I'm about to go to London
[09:37] <BradB> debonzi: yep, they're there. thanks dude.
[09:37] <debonzi> BradB, so I beliave I need to wait the "real" data to be there and than publish this packages "by hand"
[09:37] <Kinnison> kiko_bz: sabdfl and I have agreed that I'll take on gina. I'll chat with you tomorrow about it
[09:38] <cprov> Kinnison: can you send me instruction to run librarian ?
[09:38] <BradB> Kinnison: how low-tech is that!
[09:38] <debonzi> BradB, you are welcome.. if something is missing or you want to change, just ask for
[09:39] <BradB> debonzi: depends...what does "publishing" a package mean? adds it to a certain distro?
[09:42] <debonzi> BradB, yes.. we can say that
[09:43] <BradB> debonzi: so you plan to have a distro for m/s/l/r?
[09:44] <BradB> we probably shouldn't
[09:44] <BradB> unless we should
[09:44] <debonzi> BradB, if they should be available in soyuz (and I think they do) yes.. but it will probably be done later
[09:45] <BradB> i dunno, maybe that'll make some things easier to look at in the UI if they belong to a distro
[09:48] <kiko_bz> Kinnison, that's cool, I'm on it
[09:50] <BradB> spiv_: do you do nicole?
[09:50] <BradB> (pun intended)
[09:55] !alindeman:*! Hi all! Interested users from Poland: #linux.pl is a channel for Polish Linux users created for support and general Linux discussion.  Stop by if you'd like.
[09:59] <cprov> BradB: what is up w/ nicole ?
[10:00] <BradB> cprov: i just wanted to know what to tell mark if he wants to know when gina and nicole will have been run on launchpad_dogfood
[10:03] <cprov> BradB: ok, in few words:  gina will agregatte new sources on a given distro, nicole will add project/product{series/release} for them
[10:04] <BradB> yeah, i know what they do (i think), but i just wanted to know when all the "real" projects, products and source packages will be brought in.
[10:04] <kiko_bz> BradB, this is ugly. I imagine a launchpad distribution could solve problems temporarily -- that is, if it's okay to move bugs to a new package in another distro when we make up our minds :)
[10:04] <kiko_bz> BradB, however, this is crack -- doesn't malone track bugs in non-packages?
[10:04] <BradB> kiko_bz: that's why i added the launchpad distro earlier.
[10:05] <kiko_bz> yes, I realize but see my question.
[10:05] <BradB> kiko_bz: a bug is just a bug
[10:05] <kiko_bz> when.. what's the big deal about with soyuz packages? :)
[10:05] <BradB> bugs can be assigned to products and packages
[10:05] <kiko_bz> s/wh/th
[10:05] <BradB> kiko_bz: so that it looks a little more real (well, a lot more real) when sabdfl demoes it to mdz
[10:06] <BradB> which happens 6 minutes ago
[10:06] <BradB> or not, i guess
[10:06] <kiko_bz> BradB, but come on, soyuz *isn't* a package, mdz wouldn't be impressed. he would if you displayed gcc-3.3 :)
[10:07] <kiko_bz> don't we have a bugzilla importer going?
[10:07] <kiko_bz> we could import some upstream bugs related to a package we *do* have in ubuntu
[10:08] <BradB> kiko_bz: and, well, dude, it's hard for rosetta to dogfood without packages to translate.
[10:08] <BradB> because the rosetta alpha is, of course, moving into the DF
[10:08] <cprov> a bugzilla importer will rock !!! real bugs for real packages <wink>
[10:08] <kiko_bz> justdave, what's the story on the bugzilla importer?
[10:09] <kiko_bz> BradB, what's wrong with translating xchat? :)
[10:09] <kiko_bz> we could pull xchat bugs and use xchat packages and translate it too.
[10:09] <justdave> kiko_bz: it's not actually an importer, it's a watcher.
[10:09] <kiko_bz> ah, I see.
[10:10] <justdave> you file a bug in Malone, then tell it it's an upstream bug and give it which bug system and the bug number
[10:10] <justdave> then it queries the upstream bug for the status periodically and will tell you in malone what the upstream status is
[10:10] <kiko_bz> just status. not comments?
[10:10] <justdave> correct
[10:11] <debonzi> BradB, so, I already created one distro, distrorelease and now the are in ubuntu/warty... so probably you can see then in soyuz too
[10:11] <BradB> woo
[10:14] <SteveA> spiv_: ping?
[10:20] <SteveA> spiv_: never mind
[10:20] <sabdfl> hi all
[10:20] <SteveA> sabdfl: simon has come up with a way that should work to get decent names in RecentChanges
[10:20] <sabdfl> excellent
[10:20] <sabdfl> what was the trick?
[10:22] <SteveA> it isn't fixed yet.  a wiki page stores the text of who edited it.  we just need to get the name rather than the id and store that.
[10:22] <SteveA> the name will be available, we're just not sure where. 
[10:22] <SteveA> plone is now serving up correct-looking cacheing headers
[10:23] <sabdfl> cool, please thank vika
[10:23] <sabdfl> did i meet vika in vilnius?
[10:23] <SteveA> but for as yet unknown reasons, our apache isn't cacheing it
[10:23] <sabdfl> ah
[10:23] <sabdfl> bad injun
[10:23] <SteveA> no, because vika lives in israel at present
[10:23] <SteveA> vika's apache is cacheing it on her machine
[10:23] <kiko_bz> hey sabdfl
[10:23] <SteveA> it is unclear what is different
[10:24] <sabdfl> ok
[10:24] <sabdfl> hiya kiko_bz
[10:24] <sabdfl> you feeling a little pressured?
[10:24] <kiko_bz> somebody took over kiko today, I don't feel like nickserving them to death though
[10:24] <sabdfl> that's your story, is it?
[10:24] <sabdfl> chatted with kinnison after he landed
[10:25] <sabdfl> i landed
[10:25] <kiko_bz> sort of. sabdfl, we were discussing the immediate issue of the demo of malone with soyuz combo
[10:25] <sabdfl> he figures to have mawson up to speed with gina data this week, in collaboration with cprov
[10:25] <kiko_bz> we finally are getting gina to run again
[10:25] <sabdfl> ok
[10:25] <sabdfl> ok
[10:25] <BradB> sabdfl: hi. malone dogfood should be ready to rock
[10:25] <sabdfl> BradB: !
[10:26] <kiko_bz> there's an interesting question which is: do soyuz, rosetta and malone belong to a distribution?
[10:26] <sabdfl> let drums roll...
[10:26] <sabdfl> mdz round?
[10:26] <BradB> heh
[10:26] <mdz> sabdfl: yep
[10:26] <sabdfl> bradb has something to show you
[10:26] <sabdfl> should we do the walkthrough from irc in this channel, or somewhere else?
[10:27] <SteveA> it would be good for the soyuz team to watch,perhaps
[10:27] <BradB> oh, ok
[10:27] <mdz> makes no difference to me
[10:27] <cprov> sabdfl: gina runs on mawson, nicole probabily too ... I'm waiting to work with Kinnisson to have lucile and librarian support
[10:27] <BradB> i was going to do it in #malone-dogfood, but we can probably just do it here
[10:27] <sabdfl> https://launchpad.ubuntu.com
[10:27] <BradB> mdz: you'll need the client cert installed, if you don't have it installed already
[10:28] <mdz> BradB: I have it
[10:28] <sabdfl> so let's go straight into malone
[10:28] <BradB> ok, so shall we start?
[10:28] <mdz> "the" client cert?  you mean I didn't get my very own? *pout*
[10:28] <cprov> SteveA: how to get the client cert ?
[10:28] <kiko_bz> cprov, it went via email from elmo
[10:28] <kiko_bz> cprov, see your launchpad archive
[10:29] <BradB> cprov: launchpad.p12 to lp@
[10:29] <kiko_bz> save it into a file and then import it into a browser
[10:29] <mdz> BradB: where do I start?
[10:29] <kiko_bz> Edit/Preferences/Advanced/Security/Certificates on the browser
[10:29] <BradB> mdz: malone
[10:29] <kiko_bz> FF at least
[10:29] <BradB> mdz: we can pretty much go top to bottom through what's listed there
[10:29] <mdz> ok, I'm there
[10:30] <BradB> ok, so i'll let you do the actual adding and stuff
[10:30] <BradB> mdz: so first off, click "Create a new bug report."
[10:30] <mdz> ok
[10:30] <mdz> authentication dialog
[10:31] <BradB> mdz: enter your user/pass
[10:31] <mdz> which one would that be?
[10:31] <sabdfl> bradb: did we pull the data from the production db?
[10:31] <BradB> mdz: it's the dump from prod
[10:31] <sabdfl> for auth?
[10:31] <BradB> sabdfl: yes
[10:31] <sabdfl> works for me!
[10:31] <sabdfl> mdz: the same as your website access
[10:32] <BradB> mdz: by the way, you already know the basic ideas behind malone, right?
[10:32] <mdz> ok, worked
[10:32] <sabdfl> in fture we'll use a cookie auth system
[10:32] <sabdfl> so the authentication will look neater
[10:33] <BradB> indeed
[10:33] <mdz> BradB: I hope so, assuming the spec reflected my input :-)
[10:33] <BradB> oh good, wasn't there. :)
[10:33] <sabdfl> mdz: baby steps, but keep going
[10:33] <BradB> mdz: okay, so you can go ahead and enter a bug
[10:33] <mdz> shall I fill this out and submit a bug?
[10:33] <mdz> ok
[10:33] <sabdfl> file that as a bug on malone
[10:33] <sabdfl> the cookie auth thing
[10:34] <BradB> you need to choose a source package too, I think, which will be malone, of course
[10:35] <mdz> aw, no source package for ubuntu? :-)
[10:35] <mdz> ok, bug #5 created
[10:35] <cprov> BradB: sourcepackage link  crashes :(
[10:36] <BradB> cprov: not sure what you're referring to
[10:36] <BradB> mdz: okay, so next up, you can go back to the main malone screen, just for kicks
[10:36] <BradB> i.e. the malone tab
[10:36] <mdz> ok
[10:36] <BradB> the "See the complete bug list"
[10:36] <BradB> then your bug
[10:36] <cprov> BradB: simple, access https://launchpad.ubuntu.com/soyuz/distros/ubuntu/src/warty/soyuz
[10:36] <mdz> yep
[10:36] <sabdfl> we have some suprt project/product/package selection widgets under development
[10:37] <mdz> the 'show bugs you created' defaults to showing all bugs created by everyone
[10:37] <BradB> cprov: oh, dude, that's soyuz...no idea there. :)
[10:37] <mdz> BradB: yep, works
[10:37] <BradB> mdz: ok, any questions first about what you're seeing?
[10:37] <BradB> about what bits mean what, or what they might be used for?
[10:37] <BradB> if not, we'll start using them
[10:38] <mdz> BradB: the comment bit has two text input widgets
[10:38] <mdz> but they aren't labeled
[10:38] <mdz> subject and body?
[10:38] <BradB> mdz: yeah, that sucks, we'll file the bug when we're done
[10:38] <BradB> anything else?
[10:38] <kiko_bz> yes, I had seen that
[10:38] <cprov> BradB: ok, we'll  find
[10:38] <mdz> BradB: I'm fiddling
[10:38] <sabdfl> comments are still undecided
[10:39] <kiko_bz> didn't I file that bug already? hmmm
[10:39] <sabdfl> w.r.t. threading etc
[10:39] <mdz> BradB: what level of feedback are you looking for?
[10:39] <mdz> BradB: e.g., we need a couple of additional statuses
[10:39] <BradB> mdz: i just wanted to know if you had any questions about the UI you're seeing before i should you the rest of it
[10:39] <BradB> s/should/show/
[10:39] <mdz> BradB: will there be an enhanced selection mechanism for the assignee?
[10:40] <BradB> mdz: i sure hope so :)
[10:40] <mdz> currently it seems to be a combobox with every person in it
[10:40] <BradB> i think limi's onit
[10:40] <mdz> ok
[10:40] <BradB> sabdfl: is he?
[10:40] <mdz> BradB: bug watch = link to an external bug?
[10:40] <BradB> mdz: watch the bug as reported on a bugzilla somewhere
[10:40] <BradB> see its status over there
[10:40] <mdz> right
[10:40] <sabdfl> yes, we'l have better selection widgets for person, product, package, project
[10:41] <BradB> mdz: bugzilla is the only supported thing to watch right now. i can show you later the interface to where you register those.
[10:41] <mdz> BradB: what's the difference between the "add an infested" widgets on the left, and the "add package" and "add product" in the middle?  do they do the same thing?
[10:41] <BradB> mdz: no, here's the diff:
[10:42] <sabdfl> assignment vs infestation
[10:42] <BradB> mdz: "packages" and "products" and a general idea, not referring to any specific release, but rather as a way of saying to the maintainer of the package "hey, there's a bug, do something about it"
[10:42] <sabdfl> work-to-do vs versions-affected
[10:42] <BradB> yes
[10:42] <mdz> hmm
[10:42] <BradB> that's the most amazingly succint way to put it :)
[10:42] <sabdfl> hmm?
[10:42] <mdz> shouldn't an affected-version imply work-to-do?
[10:42] <sabdfl> we could put that into the process
[10:43] <sabdfl> if you said it affects that version, we can automatically add the assignment too
[10:43] <BradB> mdz: work-to-do ends up in infested versions, usually
[10:43] <mdz> what is the intended workflow?
[10:43] <sabdfl> whatever works
[10:43] <mdz> so I've submitted a bug and tied it to malone
[10:43] <BradB> malone's a bad example :)
[10:43] <sabdfl> except your bug has nothing to do with malone dude, it's YOUR bug, not mine :-)
[10:43] <mdz> let's pretend malone is packaged in Ubuntu :-)
[10:44] <sabdfl> all wrong
[10:44] <BradB> mdz: it's still early on: but basically:
[10:44] <sabdfl> hoary is a release of ubuntu, a product in the ubuntu project
[10:44] <BradB> 1. you assign the bug to sourcepackage gcc-3.3
[10:44] <BradB> 2. gcc-3.3 guy sees it
[10:45] <BradB> sabdfl: now 3. does gcc-3.3 guy add the infestations? the UI's going through puberty right now, so i'm not totally clear.
[10:45] <BradB> mdz: (because infestations will be automated eventually)
[10:45] <mdz> I should sit down and flowchart this out, really
[10:45] <mdz> based on what we've done so far in bugzilla
[10:46] <BradB> mdz: needless to say, we've had no real use of malone, so we haven't found out if our workflow sucks or not
[10:46] <sabdfl> guys, have a guest, back in an hour or two
[10:47] <mdz> BradB: right, we'll want to fold the real-world experience we've had into the workflow model
[10:47] <BradB> mdz: i think other people should be allowed to come in and add the infestations actually. anyone who sees that that bug exists in a certain release
[10:47] <BradB> mdz: in fact, a lot of people may have to add infestations
[10:48] <mdz> BradB: ah, so the difference is that the infestations are versioned?
[10:48] <BradB> mdz: infestations describe how a bug affects a particular release
[10:48] <BradB> mdz: e.g. "affected" is obvious. "dormant" means, "in this release, but we're not using the bit of the code that shows it"
[10:49] <BradB> mdz: "victimized" means "not our fault, but we're getting blamed for this bug in your package anyway!"
[10:49] <mdz> right
[10:49] <mdz> "it's your bug, but it breaks my package"
[10:49] <BradB> yes
[10:50] <BradB> whereas the product/source package (i.e. non-version) "assignments" are simply a way of getting this bug in the face of the people that need to know about it
[10:50] <BradB> and, as you'll not in the UI, each of those individuals or teams then decide the severity and priority of the bug on their own
[10:50] <mdz> yeah, I remember this from the data model
[10:51] <SteveA> sabdfl: http://www.ubuntulinux.org/wiki/FrontPage/recentchanges
[10:51] <BradB> mdz: anything stand out at you straight away that prevents warthogs from reporting bugs with this?
[10:51] <mdz> BradB: what is your name for the items which are listed  in the middle table (upstream/package, state, sev, pri, assignedto)?
[10:52] <mdz> what is each row in that table called?
[10:52] <BradB> either a product assignment or a source package assignment; they've been aggregated into one table now
[10:52] <mdz> so an 'assignment'
[10:52] <BradB> er, one *listing* in the UI that is
[10:52] <BradB> two tables in the DB, of course
[10:52] <mdz> so we can think of that as "this is what needs to be done in order to close this bug"
[10:53] <mdz> and the infestations as "this is where the bug has been observed"
[10:53] <BradB> mdz: or "the maintainers of these packages and products" have to do something about fixing this bug (for assignments)
[10:53] <BradB> mdz: and yes, that's correct for infestations
[10:54] <mdz> BradB: thinking about it, it would be nice to be able to attach a little note to each of those
[10:54] <BradB> for a liberal definition of "observed" (e.g. in the case of victimization)
[10:54] <mdz> each assignment
[10:54] <mdz> to be used as a todo list
[10:54] <BradB> hm, i guess it would
[10:54] <mdz> package X needs this change, package Y needs a different change
[10:54] <BradB> good point
[10:54] <mdz> the table would provide a very nice overview that way
[10:55] <BradB> noted
[10:55] <mdz> phone call, just a moment
[10:55] <BradB> ok
[10:56] <mdz> hmm, they hung up. never mind\
[10:58] <BradB> mdz: notifications are working on almost all the adds and edits currently, but i've left it in test mode until we fix an ownership bug. until then i'm the only one receiving the notificaiton emails.
[10:58] <mdz> BradB: are you familiar with how our bugzilla is set up?
[10:59] <BradB> mdz: nope
[10:59] <mdz> that might help to understand our existing workflow
[10:59] <mdz> ok, we have a bugzilla instance, with an Ubuntu product, and a component for every package in the distributio
[10:59] <mdz> n
[10:59] <mdz> when bugs are filed, they get assigned to a dummy user (because we don't know who will be fixing them yet)
[10:59] <mdz> copies of all bug traffic is sent to a central mailing list
[11:00] <mdz> I read that mailing list in order to triage bug reports as they come in, and to keep up with the conversations going on in individual bugs
[11:00] <mdz> when a bug comes in, it either gets a request for more information (if incomplete), or assigned to someone to fix
[11:01] <mdz> or sometimes it won't be assigned right away, because we're not yet sure what to do about it
[11:01] <mdz> the assignee will generally either debug the problem interactively with the submitter, fix it with an upload, or forward it upstream
[11:01] <mdz> bugs which are waiting for information from the submitter, or forwarded upstream, are sorted later in their todo list
[11:02] <mdz> they will check back from time to time, but for the moment, the bug is someone else's problem
[11:02] <mdz> we don't use bugzilla's NEW/ASSIGNED distinction, at least not consistently, but that's mostly because it's annoying to use
[11:03] <mdz> if the process of fixing the bug involves more than one step, all hell breaks loose, and we can't really represent that in bugzilla, so we scribble notes
[11:03] <mdz> e.g., if multiple packages need changes
[11:03] <BradB> ah
[11:03] <mdz> sometimes, a bug will be fixed for us by an upstream (mostly Debian)
[11:04] <mdz> in that case, we queue an import of the fixed version of the package, and make a notation on the bug
[11:04] <mdz> likewise if we upload a fix of our own
[11:04] <mdz> we put the bug in a PENDINGUPLOAD state
[11:04] <mdz> which indicates that we've dealt with it (lower on the todo list), but that it's still actually present in the distribution (not closed yet)
[11:05] <mdz> much of the awkwardness in the workflow, which we hope can be addressed with malone, results from the fact that bug tracking systems have different types of users with different needs
[11:05] <mdz> most obviously the user and the developer
[11:05] <BradB> malone is meant for developers
[11:06] <BradB> we leave user-handling to issue trackers
[11:06] <elmo> uh
[11:06] <elmo> say what?
[11:06] <mdz> BradB: a key interface point where users do need to interact with the bug tracking system is finding a bug
[11:08] <mdz> and interacting with the developer in collecting information, debugging, etc.
[11:08] <mdz> I could see building an issue tracker to handle the latter case
[11:08] <BradB> er, in this situation though, "users" are really "developers"...malone is meant to deal with "developers" (or people who are otherwise involved in open source, and have a really good idea of what they're doing) and "maintainers" (people who fix and improve things, based on what the former group is reporting.)
[11:09] <elmo> malone is going to need to deal with users - period
[11:09] <BradB> elmo: with suzy secretary, nope it doesn't.
[11:09] <elmo> what the hell is suzy secretary?
[11:09] <mdz> AKA "Jeff's Mum"
[11:10] <elmo> bradb: hell yes it does
[11:10] <BradB> elmo: dude, trust me, it doesn't.
[11:10] <elmo> if you want it to be of any use to a distro team
[11:10] <kiko_bz> BradB, what version of the code are you running?
[11:10] <mdz> BradB: it is a fact of life that in many cases, the person on the other end of a bug report isn't a developer-type
[11:10] <BradB> i'm just relaying sabdfl's objectives, but if you think it should also be an issue tracker, you can ask him about that
[11:10] <elmo> BradB: dude, don't go all Arch developer on us
[11:11] <mdz> he and I have discussed it, and I support the idea of a separate issue tracker
[11:11] <BradB> elmo: ^ :)
[11:11] <mdz> but that's a separate issue from users interfacing with malone
[11:11] <elmo> BradB: you have the distro team leader telling you he needs something: "no, you don't" is a good Tom Lord answer, not so good for Launchpad
[11:11] <mdz> BradB: here's a real-world scenario that happens all the time.  A user has a hardware-related bug, which is only reproducible on their system or a similar one
[11:11] <BradB> mdz: ok, what are you seeing malone needs to have to be able to be used by the warthogs?
[11:12] <mdz> BradB: we need to connect that user with the kernel maintainer and do some back-and-forth to isolate the bug
[11:12] <BradB> elmo: or, to put it more accurately, i'm just relaying the stated goals of launchpad, as per mark's specification
[11:12] <BradB> mdz: yeah, malone is meant for those people, i think
[11:13] <mdz> BradB: then another user comes along and has the same problem
[11:13] <mdz> BradB: they need to get into the mix, see if their bug really is the same, and participate in testing fixes, etc.
[11:13] <BradB> mdz: sure
[11:13] <mdz> an issue tracker provides a nice mapping from user problems to bugs
[11:13] <kiko_bz> BradB, elmo and mdz are right, though. a bugtracker should be usable by end-users, because that's a large part of the fun of participating in OSS (people pay attention to you)
[11:14] <mdz> but once they follow that link, they will be part of the bug life cycle
[11:14] <kiko_bz> it also provides a structured way of storing this information, which is essential to making heads or tails of it later.
[11:14] <mdz> anyway, this is getting a bit handwavy
[11:14] <BradB> kiko_bz: i think the main point here is the confusion about what the term "end-user" really means in this context.
[11:14] <mdz> let's focus on the system itself and how we will use it
[11:15] <mdz> BradB: so I have a bug which is assigned to malone, but that's wrong, and it needs to be assigned to Ubuntu instead. how do I change that?
[11:15] <BradB> in the edit screen
[11:16] <mdz> but it isn't there yet?
[11:16] <BradB> yeah, just click on the assignment
[11:16] <mdz> that lets me change status, priority, severity, binarypackage and assignee
[11:16] <mdz> but not the source package
[11:17] <BradB> oh, i might have been thinking of infestations allowing that to be changed then. that's a bug (it was on our todo, but not to-done yet, apparently)
[11:17] <mdz> ok
[11:17] <mdz> one thing I find confusing is that when I click on most of the fields in the assignment list, I get an interface which lets me change the value I clicked on
[11:18] <mdz> but if I click the source package, I instead get a report of bugs on it
[11:18] <BradB> it's a bit of UI weirdness
[11:19] <BradB> or goodness, depending on your point of view
[11:19] <BradB> mdz: can i clarify one thing about "users" of malone?
[11:19] <mdz> sure
[11:19] <BradB> just to give some context to further discussion:
[11:20] <BradB> so to be clear, there are three kinds of users that might use an ubuntu system (or any linux distro):
[11:20] <BradB> 1. the kind that say "where's the any key?"
[11:21] <BradB> 2. the kind that say "hey brad, we love plone and we're really keen to start using it!" or perhaps "i hack on core python in my spare time"...e.g. the people who are really part of the OS movement and making the software better.
[11:21] <BradB> 3. the people fixing the bugs reported by 1 and 2 (who might also be in group 2)
[11:21] <BradB> malone is for 2 and 3, issue trackers are for 1
[11:21] <BradB> that's the impression i got from discussing with mark.
[11:21] <mdz> my point earlier was that we cannot expect to completely isolate class-1 users from malone
[11:22] <mdz> because of the issues inherent in difficult-to-reproduce bugs
[11:22] <BradB> mdz: ok, you might want to have a word with mark to clarify that, because my understanding is that they're in no way catered to in malone.
[11:22] <mdz> BradB: I think he and I were on the same page the last time we spoke about it, but I'll raise it again to be sure
[11:24] <BradB> mdz: ok, what other things do you see in the UI that would prevent warthogs from using it?
[11:25] <mdz> BradB: tell me about the notifications
[11:25] <BradB> you'll get a notification for adding:
[11:25] <BradB> infestations
[11:25] <mdz> based on how I described our Bugzilla approach earlier, how would that map to malone notifications?
[11:26] <BradB> hm, /me thinks
[11:26] <BradB> let's put it this way (so you can subtract malone from bugzilla and see where the different is workflow-wise)
[11:27] <BradB> people can be Cc'd on a bug. anybody that's a user can be.
[11:27] <BradB> people who are Cc'd on a bug get notifications when any of the following things are added to that bug:
[11:27] <BradB> infestations
[11:27] <BradB> assignments
[11:27] <BradB> ext refs
[11:27] <BradB> watches
[11:27] <BradB> comments
[11:27] <mdz> how do I get notified of new bugs?
[11:27] <BradB> mdz: they're no support for that yet
[11:28] <mdz> ok, that should be on the critical list
[11:28] <BradB> indeed
[11:28] <BradB> there's a problem at the UI level with that though
[11:28] <mdz> oh?
[11:29] <BradB> malone needs someway of saying "this person should get notified when any bugs of this kind are submitted", but there's no UI whatsoever for that, i don't think
[11:29] <BradB> and, perhaps a distro-global notification
[11:29] <mdz> at the level of bug traffic we have now, a global notification is fine
[11:29] <mdz> all new bugs -> here
[11:29] <BradB> ah, yeah, ok, i think i remember talking with mark about a quick way to hack that in
[11:30] <BradB> it's easy enough to do
[11:30] <mdz> it's a hack in bugzilla, too
[11:30] <mdz> but it's what makes the whole thing livable for us at this point
[11:30] <mdz> every new bug and every comment go to the mailing list
[11:31] <mdz> this is core to working on bugs as a team, rather than as an individual
[11:31] <kiko_bz> agreed on that.
[11:31] <BradB> that was what i was going to mention next too...current notifications are a bit too simplistic in malone. they don't email assignees, for example.
[11:32] <BradB> global notifications are noted, i can do that in the next day or two
[11:32] <mdz> when warty-bugs starts to get close to the amount of traffic on debian-bugs-dist, we'll need fancy filters to say which bugs should go to which teams
[11:32] <mdz> but for now, we're essentially working as one team
[11:32] <mdz> BradB: if we get that, all other shortcomings of notifications can be forgiven at this stage
[11:33] <BradB> ok
[11:33] <mdz> BradB: I assume that adding new bug states is fairly trivial
[11:33] <mdz> we need several of those
[11:33] <BradB> yes
[11:33] <mdz> with an associated sort order
[11:34] <BradB> er, actually i don't think bugs have a state at the moment
[11:35] <mdz> well, there's an attribute labeled 'state' in the UI
[11:35] <mdz> whatever that is, we need more of them :-)
[11:35] <BradB> mdz: there's "Bug Status" in the assignments.
[11:35] <BradB> i see no state on a bug
[11:35] <mdz> Upstream / Package  	State  	Sev  	Pri  	Assigned to
[11:35] <BradB> yeah, that's assignments
[11:36] <mdz> ah, hmm
[11:36] <BradB> those are easy enough to change, but i guess we also have to think about a state for a bug...or maybe not
[11:36] <mdz> well, the common case is one assignment per bug, so that's workable
[11:36] <mdz> but e.g., the NEEDINFO state is generally global
[11:36] <mdz> for a bug
[11:36] <mdz> this is minor stuff, though
[11:36] <mdz> if anything, it's somewhat more flexibility than we need
[11:37] <BradB> mdz: need info is only relevant to the person who doesn't think they have enough info to go on :)
[11:37] <BradB> but in any case, something for down the road...i can add those easily to the assignments
[11:37] <mdz> BradB: in theory, yes, but in almost all real cases, the bug report as a whole is either complete or not
[11:38] <BradB> ok
[11:39] <mdz> the only missing Bugzilla feature that we actually use is the target milestone
[11:39] <mdz> which is actually a bad hack for what we really need
[11:39] <mdz> which is proper version tracking for workflow
[11:39] <mdz> "this needs to be fixed in Hoary" versus "this needs to be fixed in Hoary AND backported to Warty"
[11:40] <BradB> mdz: how would you expect that to be represented in the UI?
[11:40] <mdz> BradB: good question
[11:41] <mdz> it's a bit of a hybrid of an infestation and an assignment
[11:41] <BradB> Maybe target version: and backport to: or something
[11:41] <BradB> the latter being a list
[11:41] <mdz> one approach would be to allow an assignment to refer to a source package release
[11:41] <mdz> as well as a source package or a product
[11:42] <mdz> er
[11:42] <mdz> a dist release, I suppose
[11:42] <mdz> no, that's really awful, isn't it
[11:42] <mdz> ideally, the state of the bug in each distrelease would be implicit based on the presence of fixed/affected versions
[11:43] <mdz> but then there's a bit of policy which says "needs to be fixed with a new version to supersede this version", as distinct from "exists in this version"
[11:44] <mdz> so let's say a bug is reported against foo version 1.1-1 in Hoary
[11:44] <mdz> then we come along and confirm that the bug is also present back in 1.0-2 in Warty
[11:44] <BradB> two infestations
[11:44] <mdz> right
[11:45] <mdz> which could be used to build a simple little table of releases
[11:45] <mdz> which says hoary: affected, warty: affected
[11:45] <BradB> ah yes, of course, that makes sense
[11:45] <mdz> given that, a checkbox next to each one could be used to communicate that it needs a fix there
[11:45] <mdz> I did a mockup which sort of expressed this
[11:45] <mdz> I think I've lost it, though
[11:46] <BradB> mdz: a checkbox? hm.
[11:46] <mdz> so if a bug is marked as needing-to-be-fixed in Warty, and then a new infestation is added which shows that the bug is fixed in version X, and version X is now the current version for Warty, then it no longer needs-to-be-fixed in Warty
[11:47] <mdz> and the release status table would show it fixed
[11:47] <mdz> this relies on all kinds of soyuz data, etc. though
[11:47] <BradB> mdz: the intent is that malone does this all automatically...i hope.
[11:48] <mdz> BradB: I think we can get by OK for now with just infestations
[11:48] <mdz> for the common case, it should be clear from the display, I think
[11:48] <BradB> ok
[11:50] <mdz> so given the notifications we discussed, and if we can manage to fake the milestone feature using infestations, I think we should be in reasonable shape
[11:50] <BradB> cool
[11:50] <mdz> BradB: can we expect to have live data on source packages and releases?
[11:51] <mdz> imported from the package archive?
[11:51] <BradB> kiko_bz: ?
[11:51] <BradB> mdz: i've been hoping for it all day. :)
[11:51] <BradB> cprov and Kinnison might have a response for that too (but Kinnison's not around atm)
[11:52] <kiko_bz> yes?
[11:53] <BradB> kiko_bz: when can we expect to have live data imported on source packages and releases?
[11:53] <kiko_bz> mdz, that's done by Gina, and that's being done as we speak. We'll likely have a database up tomorrow that you can browse
[11:53] <BradB> sweet
[11:53] <mdz> kiko_bz: great!
[11:53] <kiko_bz> the database is actually quite massive but it looks very interesting
[11:54] <kiko_bz> we are getting it to run in incremental mode, so we track the history
[11:54] <mdz> the issue will be that we can't create an infestation until the version is known
[11:54] <BradB> mdz: what are your plans for when you realistically want warthogs to start using this, and how do you plan to have them start (e.g. a few at a time, or all at once?)
[11:54] <mdz> I expect that a very common operation will be to upload a package, and then go to Malone and mark it fixed in that version
[11:55] <mdz> but that version won't exist immediately
[11:55] <mdz> BradB: how feasible is it to import the existing Bugzilla data?
[11:55] <BradB> mdz: there's no way of doing that that i'm aware of. kiko_bz?
[11:56] <mdz> it isn't really feasible for us to use both systems at once
[11:56] <BradB> mdz: here's the problem with testing:
[11:56] <kiko_bz> there is no *current* way, but we could get an importer going
[11:56] <BradB> 1. malone isn't a very good test for it
[11:57] <BradB> 2. we need a few people giving this a *good* *test* (stability and real-world usability-wise) without having everyone at once using it.
[11:57] <BradB> so, ideally, we'd get a couple of maintainers using it for a couple weeks
[11:57] <BradB> a couple, a few, several, whatever :)
[11:58] <mdz> tthe problem with a couple of people using it is that they need actual bug data in it to test
[11:58] <mdz> and if that doesn't come from bugzilla, that means pointing users to malone
[11:59] <BradB> hm, rolling it out all in one shot is a big risk
[11:59] <BradB> i can see why it's difficult to have just a few people testing it though. hmmm.