[12:13] <mirak> hi*
[12:14] <mirak> why launchpad is not open source ???
[12:14] <kiko> mirak, launchpad.net/faq? :-)
[12:17] <mirak> kiko: the invoqued reason sucks
[12:17] <mirak> unless there is some proprietary code in it that must  be cleaned
[12:17] <mirak> don't know, that's weird. this is not how it's supposed to be.
[12:18] <mirak> it shouldn't be used at all probably
[12:18] <kiko> well
[12:19] <mirak> that's a bit of way
[12:19] <kiko> it's as open a project as it can be without being open source
[12:19] <kiko> and the plan is for it to be open source eventually
[12:19] <mirak> what's the interest of not putting it open source beside maintaining total control over it ?
[12:19] <mirak> and eventually not letting other distributions make use of it
[12:20] <kiko> it is still very much in the incipient stages
[12:20] <mirak> but it workks
[12:20] <sivang> mirak: any distribution are welcome to use it, there are already several.
[12:20] <mirak> I don't understand either, but I like ubuntu indeed
[12:20] <mirak> so why isnt it open source really ?
[12:21] <mirak> why just drawing so much attention about this fact ?
[12:21] <mirak> good night
[12:23] <malcc> lifeless: Yes
[12:26] <carlos> good night
[12:42] <mdz> kiko: who should be the approved for rosetta specs?
[12:42] <mdz> kiko: https://launchpad.net/products/rosetta/+spec/rosetta-oo-import-export is on the agenda for paris but has no approver
[02:53] <bradb> kiko: around?
[07:32] <spiv> jamesh: pending-reviews doesn't like Kinnison's 'launchpad-repo' directory.  Should pending-reviews cope, or should we get Kinnison to move his branches?
[07:32] <jamesh> spiv: get him to move the branches, I think
[07:34] <jamesh> iirc the rules are that the product name is the second last directory component, unless that component is numeric (in which the third last component is used)
[07:57] <SteveA> mornng
[07:58] <spiv> SteveA: Morning.  infrastructure voip call?
[08:00] <SteveA> yep
[08:02] <SteveA> stub, jamesh
[08:04] <jamesh> yep
[08:14] <stub> Yo
[08:14] <SteveA> spiv, jamesh, stub: also, #c-m for text
[08:43] <carlos> morning
[09:00] <mdke> argh, that Ruwan5 chap is creating more havoc on the wiki again
[09:04] <mdke> anyone able to disactivate the account? perhaps it was reactivated?
[09:06] <carlos> SteveA, lifeless, stub: ^^^
[09:07] <SteveA> hello carlos 
[09:07] <carlos> SteveA: hi
[09:07] <carlos> SteveA: could you take a look to mdke's request?
[09:08] <mdke> SteveA: hi. A user who appears on the wiki as Ruwan5 is going around and deleting or replacing some quite important pages, it seems accidentally. The same happened a few weeks ago, and lifeless deactivated his account, and I emailed him. But I had no reply, and I noticed that now the same thing is happening
[09:11] <mdke> for some reason the pages he deletes seem to lose their history too, so become hard to revert
[09:13] <SteveA> darn
[09:14] <SteveA> we don't have a simple "disable this account" flag in launchpad yet
[09:14] <mdke> I can't remember how he did it
[09:14] <SteveA> but stub and spiv should be able to get the thing sorted, and get the wikis to disable the login
[09:14] <mdke> oh hang on
[09:15] <mdke> I have an email from him
[09:15] <mdke> saying sorry and that he won't do it again. I'll reply
[09:16] <SteveA> ok
[09:17] <stub> So don't nuke the account?
[09:18] <jamesh> stub: http://dev.mysql.com/doc/refman/5.1/en/insert-on-duplicate.html <- is this the sort of SQL extension you were thinking of?
[09:19] <stub> jamesh: Yes
[09:20] <mdke> stub: is there some way of suspending it for editing on the wiki?
[09:31] <stub> mdke: I'm sure there is, but I don't know how. I can nuke it in the database manually but I think the wiki's cache auth credentials and something needs to be cleared manually
[09:32] <mdke> stub: alright, I've emailed him and we'll see if the problem persists. If it does, I'll come back
[10:01] <carlos> stub: hi, would you review my bug-35631 branch?
[10:02] <carlos> stub: the code review is done and approved already
[10:02] <carlos> stub: and I'm running the migration script atm using staging's database
[10:03] <carlos> stub: I found a problem with production data and it's fixed now, but I guess it would take a couple of hours to reach jamesh's page, if you want, I could send you the new migration script code
[10:11] <janimo> hey, what is the difference between subscribers and 'also notified' in malone?
[10:11] <janimo> I unsubscribed from some bugs yesterday and did not expect to be still notified about changes to those bugs
[10:15] <BjornT> janimo: you're a subscriber if you (or someone else) subscribed you to the bug. you're also notified if you are related to the bug, for example if you are the assignee, bug contact, product owner, etc.
[10:19] <ddaa> Heya, feedback requested on https://staging.launchpad.net/bazaar
[10:29] <lifeless> morning all
[10:36] <janimo> BjornT: https://launchpad.net/distros/ubuntu/+bug/42395
[10:36] <Ubugtu> Malone bug 42395 in Ubuntu "live- ubuntu and kubuntu 6.06Beta fail for mac G5 " [Medium,Unconfirmed]  
[10:37] <janimo> I was affected by it but now it is rejected for that component.
[10:37] <janimo> So I think it should no longer notify me. Other than that is there a mail cmd to tell it to not cc me?
[10:40] <sivang> morning
[10:41] <BjornT> janimo: sorry, no way of stopping the notifications. feel free to file a bug about it, though, i agree that it should be possible.
[10:42] <janimo> BjornT: ok I will. Otherwise if someone mistakenly assigns a bug to  package it is no way of getting unsubscribed.
[10:42] <janimo> sivang: hey
[10:42] <sivang> hey janimo , 'sup ?
[10:43] <janimo> seems like we're roomies next week ;)
[10:46] <sivang> janimo: ah, we are?! cool! but I did not get a new delgates list yet , how do you know about it?
[10:46] <janimo> sivang: did you not get a mail yesterday from claire?
[10:47] <sivang> I did, but I couldn't who's my roomie :-)
[10:47] <janimo> there are attachments in the mail :)
[10:48] <sivang> 2 of them, an excel sheet and directions
[10:49] <janimo> the first has rooms list. let's continue in PM though since it's  OT here
[10:50] <lifeless> SteveA: I want to test skype, are you around ?
[10:53] <SteveA> lifeless: hello
[10:53] <lifeless> yoyo
[10:57] <SteveA> lifeless: i am running skype now
[10:57] <lifeless> shat skype address ?
[10:57] <lifeless> *what*
[10:57] <SteveA> "implied"
[10:59] <lifeless> could you hear me? I could not hear you
[10:59] <SteveA> sound problem at my end
[11:00] <SteveA> try again
[11:01] <SteveA> sound problem at my end again
[11:03] <SteveA> i did a successful echo test
[11:03] <SteveA> you are displayed as not currently online
[11:11] <Kinnison> jamesh: ping?
[11:24] <Yannig> Hello everybody :)
[11:31] <sivang> is there a way to indicate that I am going to fix a bug upstream in the bug task?
[11:36] <carlos> I need a reviewer for a preimplementation call
[11:37] <carlos> jamesh, BjornT: Are you too busy? I don't mind to have it tomorrow
[11:37] <carlos> should be a fast call
[11:40] <SteveA> carlos: we can talk
[11:41] <carlos> SteveA: ok
[11:41] <carlos> thanks
[11:41] <SteveA> carlos: can we have it in 10 mins?
[11:42] <carlos> SteveA: sure
[11:42] <SteveA> ok
[11:48] <Kinnison> SteveA: Do you have any idea why my branches aren't activating on the branch summary page?
[11:54] <SteveA> Kinnison: maybe some problem with the repository.  perhaps jamesh has an error log
[11:54] <SteveA> carlos: be with you very shortly
[11:54] <carlos> SteveA: ok, thanks
[11:55] <Kinnison> SteveA: thanks
[11:58] <carlos> fuck, I hate skype!
[11:58] <jamesh> Kinnison: the problem is the directory names
[11:58] <SteveA> as in, it needs to say "launchpad" not "launchapd-repo" ?
[11:58] <jamesh> Kinnison: the second last directory component (launchpad-repo) does not match any of the rocketfuel branch names
[11:59] <SteveA> jamesh: could the script be changed to look at bzr info related branches?
[12:00] <jamesh> SteveA: That is an option.  Check if the branch contains a particular revision in its history or ancestry
[12:02] <Kinnison> Irritatingly I don't think bzr info shows the chinstrap branch because it's branched from a branch as it were
[12:03] <jamesh> Kinnison: if you grab the branch's revision history, it probably includes "Arch-1:rocketfuel@canonical.com%launchpad--devel--0--base-0" though
[12:04] <jamesh> which would give a good indication that the branch's parent is launchpad
[12:06] <jamesh> of course, there are benefits to requiring some level of consistency in branch naming
[12:06] <Kinnison> Indeed. I'm trying to decide how hard it'll be for me to modify my scripts to use different path names locally and on chinstrap
[12:06] <Kinnison> I have ~/dev-canonical/launchpad-repo y'see
[12:10] <jamesh> Kinnison: the two options that would keep the script happy in its current form would be (a) to rename launchpad-repo to launchpad or (b) name your branches as launchpad-repo/launchpad/$branchname
[12:10] <Kinnison> If it'll sort things out in the meantime I can make a symlink
[12:10] <jamesh> I suppose picking a parent based on ancestry would be preferable though
[12:10] <Kinnison> jamesh: I like the latter, but I'll do it via symlink if that'll work
[12:11] <Kinnison> when is the script due to start again?
[12:13] <jamesh> it is currently running once every 2 hours
[12:13] <jamesh> seems to be in the middle of a run right now
[12:14] <Kinnison> arse
[12:14] <Kinnison> so it'll be 1200UTC before it tries again
[12:23] <stub> carlos: How long does that script take to run?
[12:23] <stub> Kinnison: Can I roll out r3662 to drescher, or are there later patches that need to be cherry picked?
[12:24] <Kinnison> stub: You really need to check with cprov since thus far pqm has been rejecting my advances
[12:25] <Kinnison> stub: Looks like there is stuff after 3662 which might be relevant so I'd leave drescher's codeline alone for now.
[12:26] <stub> Kinnison: ok
[12:26] <stub> carlos: https://chinstrap.ubuntu.com/~dsilvers/paste/fileZ1LWGa.html
[12:29] <lifeless> jamesh: ping
[12:30] <jamesh> lifeless: pong.  Will send the reviews through shortly
[12:30] <lifeless> thank you. What caused the holdup ?
[12:30] <stub> carlos: I'm asking because it looks like that script will need to execute at least 60 million queries...
[12:30] <carlos> stub: it's being slow
[12:31] <stub> carlos: Do you have an estimate? I'm wondering if it should be refactored or if the script is good enough for a one off migration
[12:34] <carlos> stub: I'm in a phone call, give me some time and will talk about it..
[12:50] <carlos> stub: hi, I'm ready
[12:50] <stub> carlos: Slightly changed and approved patch - https://chinstrap.ubuntu.com/~dsilvers/paste/fileZ1LWGa.html
[12:50] <carlos> stub: hmmm, I lost my staging database connection
[12:51] <carlos> stub: ok, thanks
[12:51] <stub> I was just wondering if you knew or could estimate how long the migration script was going to take. That many queries could take days.
[12:51] <carlos> stub: yes, I could estimate it
[12:52] <carlos> let me see if asuka let me see the output...
[12:56] <carlos> It did 235000 rows in about 2 hours 50 minutes (1382 rows/min) and we have 28234032 rows so it would take: ...
[12:56] <carlos> hmm, we need to change it...
[12:56] <carlos> 14,1 days...???!!??
[12:56] <stub> Sounds about right ;)
[12:56] <stub> Although on Jubany it would take about half that
[12:57] <carlos> stub: also, I don't know why, seems like I have memory leaks
[12:57] <carlos> I tried to keep the amount of sqlobjects in memory as low as possible
[12:57] <stub> SQLObject code has that tendancy. There might be magic commands to clear the caches.
[12:59] <carlos> stub: I suppose I could optimize it doing some extra queries getting the IDs that have duplicated entries that should be fixed
[01:00] <carlos> that would require some expensive queries executed first, but I don't think it would take more than some hours to get it done (much better than more than 5 days ;-))
[01:00] <stub> carlos: I think what we need to do is retrieve a list of all interesting information in a single query. Iterate over those results keeping the duplicate list in ram or in a temporary table (or possibly just removing them as we go)
[01:02] <stub> And once we are done, recalculate all the pofile latest submissions
[01:03] <carlos> well, not all, but the ones that have that field set to NULL
[01:03] <carlos> so it should be quite easy and fast
[01:04] <carlos> stub: ok, will do it that way and request a new review when it's ready (and takes less than one day to have it done in asuka) :-P
[01:04] <carlos> stub: thanks
[01:09] <stub> carlos: What does pomsgset.getSelection() return?
[01:10] <carlos> stub: a rown of POSelection table
[01:10] <carlos> s/rown/row/
[01:11] <stub> which one?
[01:11] <carlos> the one related to that pomsgset object
[01:12] <carlos> or None if we didn't create it yet
[01:19] <stub> carlos: So you could just iterate over a query like https://chinstrap.ubuntu.com/~dsilvers/paste/fileoByEIt.html ? I think it is just a case of keeping some state.
[01:27] <ddaa> stub: did you just bounce the database server on the pqm system?
[01:28] <stub> ddaa: No
[01:29] <stub> ddaa: I'm running the test suite on that box - pqm is currently disabled
[01:30] <ddaa> stub: one merge request failed with "OperationalError: could not connect to server: Connection refused" in test_reconnector...
[01:30] <ddaa> anyway, resending
[01:30] <stub> ddaa: That test is flakey still :-(
[01:45] <carlos> stub: and I guess we should get the SQLObject from the ids in those queries, right?
[01:45] <carlos> stub: or do you think I should use raw SQL UPDATE commands?
[01:45] <carlos> both would fit
[01:46] <carlos> my only concern is the SQLObject memory usage
[01:46] <stub> carlos: Raw SQL so you don't have to worry about memory leaks or side effects. SQLObject is sucky for batch processing.
[01:47] <carlos> ok
[01:47] <carlos> then I will use SQLObject at the end to fix the IPOFile.latestsubmission fields
[01:48] <carlos> stub: thanks
[01:49] <salgado> hmmm. is the arch-commits list down?
[01:49] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downime is 15 minutes.
[01:50] <Znarl> salgado : Why do you ask?
[01:51] <salgado> Znarl, because I merged some changes yesterday but no email notification reached that list
[01:51] <salgado> yes, r3672 on rocketfuel. 
[01:52] <salgado> the last notification on arch-commits is for r3668 (launchpad, that is)
[02:28] <Kinnison> SteveA: I firmly believe my small-fixes branch can be merged [trivial]  do you agree? https://chinstrap.ubuntu.com/~jamesh/pending-reviews/dsilvers/launchpad-repo/launchpad/small-fixes/full-diff
[02:31] <SteveA> Kinnison: is there a possibility of this crontab directory pruning running concurrently with something that is creating directories in that area?
[02:32] <Kinnison> no, it's within the cron.daily which holds the archive lock
[02:33] <SteveA> how is an empty directory "redundant" ?
[02:33] <SteveA> maybe you mean "unused" or "useless"
[02:33] <SteveA> UAID: Unused Array of Inexpensive Disks
[02:35] <SteveA> anyway, in answer to your question, i'm sure it could be merged as trivial.  were i to review it, i would point out what i already pointed out
[02:36] <SteveA> and ask why we have empty directories created, which much then be cleaned up
[02:36] <elmo> for the same reason dak does
[02:37] <elmo> it's a simpler implementation to not have the code  check  for empty directories and remove them when purging packages (because that's racy), but rather do the trivial find  during cron.daily
[02:38] <SteveA> i still don't understand where empty directories come from
[02:38] <SteveA> although you have explained why to remove them at that point rather than as going along
[02:39] <elmo> SteveA: from packages that have e.g. been renamed
[02:39] <lifeless> BjornT: can you do ddaa's 'urgent' branch ?
[02:39] <SteveA> elmo: i see.  thanks
[02:41] <BjornT> lifeless: sure
[02:43] <lifeless> thanks
[02:51] <Kinnison> jamesh: I was following your instructions on using repositories with launchpad development but I can't get the pqm-submit plugin working right
[02:54] <BjornT> Kinnison: what's wrong? do you use 'bzr push' to push the branch to chinstrap?
[02:55] <Kinnison> BjornT: I do
[02:56] <BjornT> Kinnison: without knowing exactly what problem you're having, i'd guess it's because of bug 33430
[02:56] <Ubugtu> Malone bug 33430 in bzr "Lack of cascading configs cause push to obscure directory settings" [Medium,Confirmed]  http://launchpad.net/bugs/33430
[03:00] <matsubara> Kinnison: bug 45306 may also help
[03:00] <Ubugtu> Malone bug 45306 in bzr "LocationConfig should look for options on parent locations when they're not found" [Medium,Unconfirmed]  http://launchpad.net/bugs/45306
[03:02] <Kinnison> posibly, it always uses bazaar-ng.org as the target
[03:03] <Kinnison> it's getting the chinstrap url right for my branch
[03:05] <mpt> 09:02:37@2006-06-bug-attachments> bzr push
[03:05] <mpt> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/2006-06-bug-attachments
[03:05] <mpt> bzr: ERROR: File exists: '/home/warthogs/archives/mpt/launchpad/2006-06-bug-attachments': Failure: unable to mkdir
[03:08] <mpt> Of course it exists, that's why I'm trying to push to it
[03:08] <lifeless> mpt: if it alreadu exists, it must not be a branch
[03:08] <lifeless> as in, to get that error
[03:09] <mpt> lifeless, it's a half-pushed version of the branch before the Internet connection died
[03:09] <mpt> s/before/up to when/
[03:09] <mpt> so do I have to start from scratch?
[03:11] <matsubara> try with the rspush 
[03:12] <mpt> bzr: ERROR: No rspush location known or specified.
[03:12] <mpt> should that be x-rspush-data?
[03:12] <matsubara> no idea, never used it before. :-)
[03:13] <mpt> bzr: ERROR: Invalid rsync path u'sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/2006-06-bug-attachments/'.
[03:13] <mpt> hmm
[03:13] <mpt> chinstrap:/...
[03:13] <mpt> bzr: ERROR: Internal check failed: file u'/home/mpt/hacking/lp/2006-06-bug-attachments/sourcecode' entered as kind 'directory' id 'x_David_Allouche_<david.allouche@canonical.com>_Mon_Jun_28_09:59:21_2004_32213.0', now of kind 'symlink'
[03:14] <lifeless> mpt: you need to rm the half-pushed branch
[03:15] <mpt> righty-ho
[03:16] <Kinnison> Aha, it doesn't fall back on the repo data for the upstream branch, okay I can cope
[03:27] <mpt> bradb, 2006-06-bug-attachments has finished pushing
[03:36] <bradb> mpt: cool, thanks.
[03:39] <Kinnison> salgado: Any idea when you'll be able to get to my queue-uniqueness branch?
[03:39] <salgado> Kinnison, today! I have the diff open on my editor already. 
[03:40] <Kinnison> salgado: cool
[03:47] <salgado> SteveA, around?
[03:47] <Kinnison> uhoh, is my code that bad?
[03:52] <salgado> no, I haven't started reviewing it yet. it's something else that I need to talk to SteveA about
[03:53] <Kinnison> phew
[04:09] <carlos> stub: hmm I think you did a mistake documenting the revision number we are running on production
[04:10] <carlos> last week, you rolled out: r3643 and this weeek, you rolled out: r3642.... I guess the right one is r3662
[04:10] <stub> Yes - 3662
[04:11] <carlos> stub: I detected it because my last merge was r3663... and seems like I was late to get it included this week ;-)
[04:12] <stub> I look for merges that touch that many files to use as delimiters in selecting what to roll out :-)
[04:19] <looksaus> how do I enable malone bug reporting for my newly registered project in launchpad?
[04:21] <looksaus> at first sight, I don't see an option to do so
[04:21] <neutrinomass> Apparently one cannot change a bug's importance without accepting it first anymore... is this intended behaviour or should I report it as a bug ?
[04:22] <looksaus> ah, sorry, found
[04:22] <salgado> looksaus, that is done on a per-product basis
[04:22] <looksaus> salgado, sorry, should have checked more carefully
[04:23] <looksaus> salgado, are there any plans to make it possible to import a tarball just via http?
[04:24] <salgado> looksaus, no worries. the links on the upper left menu are not so easy to parse. sometimes even though I know there's a link there for something I want to do, I can't easily find it
[04:25] <looksaus> I'm just looking for a low overhead way to have vcs and bug reporting for an ubuntu locoteam project
[04:25] <salgado> looksaus, I never heard of plans for doing that. but ddaa is the one to answer it
[04:25] <ddaa> hu
[04:26] <ddaa> I know nothing of the specificities of ubuntu locoteams.
[04:26] <looksaus> if I need to install an ftp (or svn or cvs) server first to create a source base
[04:26] <salgado> ddaa, <looksaus> salgado, are there any plans to make it possible to import a tarball just via http?
[04:26] <ddaa> hu?
[04:26] <ddaa> import a tarball?
[04:26] <ddaa> wget imports tarball via http just fine here...
[04:26] <looksaus> ddaa, currently, there is the possibility to import a tarball into launchpad
[04:27] <salgado> looksaus, I guess what you want is to create a bzr branch and publish it on the supermirror
[04:27] <ddaa> looksaus: something about populating translation templates?
[04:27] <looksaus> I want to have launchpad handle as much of the admin work as possible
[04:27] <looksaus> I know _very_ little about bzr, but willing to learn
[04:27] <ddaa> mid July there's a sprint planned about integrating Rosetta and Bazaar.
[04:28] <looksaus> it's not about bazaar-rosetta integration
[04:28] <ddaa> afaik, the plans are to be able to import and export translations from/to bzr branches
[04:28] <looksaus> we're making a map of local ubuntu volunteers, see http://map.ubuntu-be.org/nl
[04:29] <salgado> no, I guess it's about importing a source tarball for an existing product instead of periodically importing from cvs/svn
[04:29] <looksaus> exactly
[04:29] <looksaus> so that we can use the original version in launchpad as the basis for our work
[04:29] <salgado> looksaus, if you don't have a VCS already, then what you shoud do is create a bzr branch for your product and publish it on the supermirror, I think
[04:29] <ddaa> looksaus: what does this map have to do with version control, bug tracking, or translations?
[04:30] <looksaus> ddaa, we want to version control the source code behind it
[04:30] <looksaus> but I think salgado probably just gave me the answer
[04:31] <ddaa> looksaus: does that make sense to you? https://staging.launchpad.net/bazaar
[04:31] <looksaus> I might have had to read about bzr first before asking this question
[04:31] <looksaus> ddaa, yes, thx
[04:32] <looksaus> sorry for bothering you with this
[04:32] <ddaa> absolutely not
[04:32] <looksaus> I'm not a technical person
[04:32] <ddaa> looksaus: I'm interested in improvement suggestions for this page, before it gets put in production
[04:32] <looksaus> I just made some hairy php code to get things going
[04:34] <SteveA> salgado: hello
[04:35] <looksaus> ddaa, it would probably make sense to have people import something really simple
[04:37] <SteveA> mpt: ping
[04:49] <looksaus> ddaa, it would probably make sense to have people import something really simple
[04:49] <looksaus> (like a tarball)
[04:50] <looksaus> and then get used to bzr afterwards
[04:50] <looksaus> I mean, I will now have a look at bzr first, obviously, and no problem
[04:50] <looksaus> but if you want as many people as possible to use this system, that could be a good idea
[04:51] <looksaus> does that make sense to you?
[04:52] <looksaus> ah, it does something already...
[04:52] <looksaus> sorry, didn't read beyond the bottom of the page!
[04:58] <SteveA> mpt: ping
[04:58] <ddaa> looksaus: launchpad does not want to be a free hosting service, like sourceforge
[04:58] <looksaus> ddaa, ok
[04:59] <looksaus> good to know
[04:59] <ddaa> the bzr hosting service is here to help developer share code more easily, using bzr
[04:59] <ddaa> but there is no plan to offer generic hosting for web pages, release tarballs etc.
[04:59] <ddaa> at least, as far as I know
[05:00] <looksaus> of course not
[05:00] <ddaa> on the other want, we do want as many people as possible to use bzr :)
[05:01] <ddaa> and my job is to materialise such incentive in the form of launchpad features
[05:02] <looksaus> you understood what my problem was?
[05:02] <looksaus> I didn't know much about bzr yet
[05:02] <ddaa> I am not sure :)
[05:03] <looksaus> and I just wanted to use some version control system
[05:03] <looksaus> with the least fuss and admin work possible
[05:03] <ddaa> right, that's all?
[05:03] <looksaus> so I thought, hey, let's import what we have into launchpad some way
[05:03] <looksaus> and they'll do the vcs hosting stuff
[05:04] <ddaa> sure
[05:04] <looksaus> then I went looking in launchpad how to import things
[05:04] <ddaa> okay
[05:04] <looksaus> and I saw something about bzr
[05:04] <looksaus> or cvs or svn or ftp
[05:04] <salgado> BjornT, I just updated MaloneEmailInterfaceUserDoc to match the malone simplification changes. can you check it, to make sure it's correct? also, is there any other wiki pages that need to be updated?
[05:04] <looksaus> as import possibilities
[05:04] <ddaa> looksaus: I see
[05:05] <looksaus> no http
[05:05] <looksaus> ddaa, do my initial comments make more sense now?
[05:05] <ddaa> yes
[05:05] <ddaa> you were confused, for good reason
[05:06] <ddaa> looksaus: what you saw is a mish-mash of at least two features: vcs-imports, and hct import
[05:06] <salgado> BjornT, SteveA, btw, I think we should move MaloneEmailInterfaceUserDoc to help.launchpad.net, right?
[05:06] <SteveA> yes
[05:06] <BjornT> salgado: well, for one thing, you edited the wrong page. https://help.launchpad.net/UsingMaloneEmail is the right one.
[05:06] <SteveA> i think bjorn was going to version it too
[05:06] <ddaa> looksaus: I would like to separate vcs imports in a way they would make more sense
[05:07] <ddaa> looksaus: but what you are looking for is hosted bzr branches
[05:07] <salgado> ah, great
[05:07] <ddaa> looksaus: you need to register a ssh public key in launchpad
[05:07] <ddaa> then create a bzr branch on your workstation
[05:07] <ddaa> and bzr push to sftp://bazaar.launchpad.net as explained on the page I pointed you at.
[05:08] <ddaa> it's very much intended to be as fuss-free as we could make it 
[05:08] <looksaus> thx
[05:09] <ddaa> ask if you have any problem doing that
[05:09] <salgado> BjornT, SteveA, okay, so I'll update the right one this time and will change the content of the old one to have only a link to the new one. is that okay?
[05:09] <ddaa> looksaus: I have a todo item to blog about this feature this week, so I'm very interested in your experience.
[05:11] <looksaus> ddaa, will do
[05:12] <looksaus> (bit busy now, at work :)
[05:12] <BjornT> salgado: well, it could be good to have it on the development wiki as well (especially with a version field). that way we could edit the documentation before the change gets rolled out.
[05:15] <salgado> BjornT, well, if that's user documentation, I don't see a good reason for changing it before it's rolled out and then having to port the changes to the other wiki once it's rolled out. I think keeping them in sync will be a problem (it already is, in fact)
[05:16] <SteveA> wow... if you search for "current time in $city" in google
[05:16] <SteveA> you get it displayed from google as the first results
[05:18] <BjornT> salgado: one of the problems with keeping the documentation in sync with the implementation today is that you can edit the documentation only after it has been rolled out (which often mean you forget to do it). i'd think it'd be easier if you could edit the documentation directly after you've finished the implementation.
[05:19] <SteveA> unfortunately, google thinks the most important st. petersburg is the one in florida USA
[05:20] <stub> google earth has a utterly useless search for most of the world - it doesn't even recognize capital cities or countries.
[05:20] <salgado> BjornT, but you'd still need to copy the changes from one wiki to the other, once it's rolled out
[05:24] <LarstiQ> SteveA: also does not work well for Den Haag
[05:26] <mpt> SteveA, pong, but I might be slow replying
[05:26] <SteveA> mpt: i want a 5 minute irc chat with you sometime
[05:32] <kiko> good morning!
[05:33] <mpt> SteveA, probably the next time when I'm free and you're awake is in about 21.5 hours
[05:33] <SteveA> mpt: surely you can spare me 5 minutes
[05:33] <mpt> Unless I skip lunch, but I had hardly any breakfast
[05:34] <SteveA> i'm not talking about 5 minutes plus 30 minutes.  i'm talking about five minutes.
[05:34] <mpt> I'm aware of that
[05:34] <mpt> ok, how about in ~25 minutes?
[05:34] <SteveA> sure
[05:35] <SteveA> i'll be here.  ping me
[05:37] <SteveA> salgado: ping
[05:39] <salgado> SteveA, pong
[05:40] <SteveA> salgado: i have 20 mins right now
[05:40] <salgado> great
[05:41] <salgado> SteveA, so, there are two pages that list all unofficial and disabled mirrors
[05:41] <SteveA> salgado: would this be better with a voice call?
[05:41] <salgado> SteveA, could be.
[05:43] <salgado> SteveA, should I call now?
[05:43] <SteveA> salgado: i'm on skype
[05:50] <kiko> salgado, thanks for following up with that
[05:50] <kiko> uhhh
[05:51] <kiko> SteveA, I think the commits mailing list is also borked.
[05:52] <salgado> kiko, it was, but Znarl said it's fixed now
[05:52] <kiko> salgado, do we not get the emails that were dropped though?
[05:53] <salgado> yes, he said these emails may have been lost
[05:54] <bradb> kiko: can i merge my unsubscribe from private bugs branch?
[05:56] <SteveA> hi kiko
[05:56] <SteveA> the mails should still get through
[05:56] <SteveA> although they may need some manual shoving
[05:56] <SteveA> from karl
[05:58] <kiko> okay
[05:58] <kiko> bradb, I haven't read the patch yet, will do so after lunch
[05:58] <bradb> kiko-fud: thanks!
[06:21] <mpt> (SteveA, I haven't forgotten, meeting's still going on)
[06:22] <SteveA> thx
[06:27] <jelmer> Any chance somebody with lp admin rights can change the maintainer of the bzr-gtk product to 'bzr'
[06:27] <jelmer> ?
[06:32] <bradb> kiko-fud: mpt cleaned up my comment/attach UI too, so I can show you that after lunch and land it today too.
[06:33] <SteveA> jelmer: are you  Jelmer Vernooij   ?
[06:33] <SteveA> if so, you should be able to do that
[06:33] <SteveA> using the "change maintainer" link
[06:36] <jelmer> SteveA: I can't, because of bug 41639
[06:36] <Ubugtu> Malone bug 41639 in launchpad "Product owner should be able to reassign ownership to another user." [Medium,Confirmed]  http://launchpad.net/bugs/41639
[06:36] <SteveA> ok
[06:37] <SteveA> jelmer: ok, sent me a gpg signed email asking for this, using the key registered on your launchpad account.  steve at canonical.com
[06:38] <SteveA> and i will do it on receipt
[06:39] <jelmer> done
[06:41] <SteveA> jelmer: done
[06:41] <jelmer> SteveA: Thanks!
[06:48] <Kinnison> Umm, pqm ate my commit
[06:48] <Kinnison> I have had no mail from it
[06:48] <Kinnison> yet it was in the queue
[06:56] <mpt> SteveA, ping
[06:57] <SteveA> mpt: ping
[06:57] <SteveA> mpt: privmsg
[06:58] <seb128> changing bug importance seems to be broken
[06:58] <seb128> it's displayed as a label instead of a list of choices, is that a known issue?
[06:58] <seb128> is there a team membership required for that?
[07:00] <seb128> bradb: around?
[07:05] <jordi> SteveA: any news from the list creation dp.?
[07:05] <jordi> dpt. even
[07:05] <SteveA> jordi: no
[07:05] <jordi> yay.
[07:05] <kiko> bradb, ah, very nice, please show that off too
[07:14] <highvoltage> hi there. is there a way to search for packages with the most bugs  in launchpad?
[07:14] <highvoltage> like a 'top 10' list or something?
[07:24] <ruffneck> hi
[07:26] <SteveA> jordi: ping
[07:28] <mpt> highvoltage, not at the moment as far as I know
[07:28] <jordi> SteveA: okay
[07:28] <highvoltage> mpt: ok
[07:28] <mpt> interesting idea though
[07:28] <mpt> maybe you could report a bug asking for it
[07:39] <bradb> h
[07:40] <seb128> kiko: ping?
[07:40] <kiko> seb128, pong
[07:40] <kiko> what's up my man
[07:40] <seb128> anybody from the launchpad team who cares to look why changing bug importance is not possible? It's sort of useful to work
[07:41] <seb128> kiko: I'm trying for one hour to figure why I'm not authorized to change the bugs importance from "untriaged"
[07:41] <kiko> bradb, ping.
[07:41] <seb128> setting something else for the bugs I triage would actually be useful :p
[07:42] <kiko> seb128, it sounds like fallout from bradb's importance fix, but it's odd.. unless you are not a member of ubuntu-core-dev
[07:42] <kiko> let me check.
[07:42] <seb128> I'm a member of that group
[07:42] <seb128> and pitti has the same issue
[07:42] <seb128> so that's probably not specific to my account
[07:43] <kiko> seb128, can you explain the symptom? do you actually see the importance dropdown?
[07:43] <seb128> no
[07:43] <seb128> just a label
 it's displayed as a label instead of a list of choices, is that a known issue?
[07:43] <seb128> as said some time ago ;)
[07:44] <bradb> seb128: so, somebody should add you to the bug contact team, ubuntu-bugs
[07:44] <kiko> that's odd.
[07:44] <kiko> bradb, no.
[07:44] <kiko> bradb, we explicitly said that it would be additive
[07:44] <kiko> bug contact team /and/ launchpad.edit
[07:44] <bradb> my understanding was that it was either/or
[07:44] <kiko> and the code seems to do it correctly
[07:45] <kiko> no
[07:45] <kiko> you will remember I commented saying that either/or would be confusing.
[07:45] <kiko> but the code seems to do the right thing
[07:45] <bradb> i think we're talking past each other
[07:45] <bradb> we're probably arguing the same thing
[07:46] <kiko> possibly
[07:46] <kiko> I said that it shouldn't be exclusive or
[07:46] <kiko> i.e.
[07:46] <bradb> you can change the importance if you are either a bug contact, or you have launchpad.Edit permission on the distribution
[07:46] <kiko> right
[07:46] <kiko> exactly
[07:46] <kiko> oh
[07:46] <kiko> I see
[07:46] <kiko> seb128 isn't a member of ubuntu drivers.
[07:47] <kiko> that's where I got it wrong.
[07:47] <kiko> sorry about that bradb :)
[07:47] <bradb> no worries
[07:48] <bradb> whatever team you think is the better choice, i'm not bothered. but we need somebody with appropriate perms to do whatever you think is better.
[07:48] <seb128> kiko: is that a bug, or should I ping somebody to be listed by ubuntu-drivers team then?
[07:48] <bradb> like mdz!
[07:48] <kiko> :)
[07:48] <mdz> you rang?
[07:49] <seb128> mdz: please let me edit bugs importance again :p
[07:49] <kiko> mdz, changing importance is limited to distribution owners or distribution bug contacts.
[07:49] <mdz> kiko: seb128 is a distribution bug contact
[07:49] <kiko> mdz, the easiest and most correct fix would be adding seb128 to bug contacts
[07:49] <kiko> okay.
[07:49] <mdz> if he were in ubuntu-drivers he might be tempted to rename ubuntu to sebuntu
[07:50] <seb128> lol
[07:50] <kiko> seb128, your choice now: do you want to be in the Ubuntu QA team, or in Ubuntu bugs?
[07:50] <seb128> I'm already member of the bugsquad team, what difference?
[07:50] <kiko> oh, bugsquad?
[07:51] <mpt> maybe the bugsquad is a vestige?
[07:51] <kiko> seb128, mdz: should bugsquad be added as a member of ubuntu-bugs?
[07:51] <mdz> sfllaw: what's meant to be the difference?
[07:51] <kiko> mpt, bugsquad has 91 members!
[07:51] <seb128> what is "ubuntu-bugs" supposed to be?
[07:51] <mdz> ubuntu-bugs was created only to drive ubuntu-bugs@lists
[07:51] <kiko> I see.
[07:51] <mdz> bugsquad was created later to organize volunteers helping with bug triage
[07:52] <mpt> kiko: and?
[07:52] <kiko> mpt, so it's certainly not vestigial :)
[07:52] <seb128> do we need a bugsquad and a qa team?
[07:52] <mpt> I don't see what size has to do with it
[07:52] <kiko> mpt, well, it is actively used, bugsquad.
[07:53] <seb128> they are sort of the same no?
[07:53] <mpt> If Malone has a defined slot for "people who can change importance of bugs on X", then people who can change importance of bugs should go in X
[07:53] <kiko> seb128, that's the question I think mdz is asking sfllaw 
[07:53] <seb128> oki
[07:53] <mpt> regardless of how many of them there are
[07:53] <kiko> seb128, for now I will add bugsquad to ubuntu-bugs
[07:53] <kiko> okay?
[07:53] <seb128> kiko: as you prefer, fine with me
[07:53] <seb128> being listed by the qa team or that doesn't make a real difference to me
[07:54] <seb128> as far as I can edit the bugs again ;)
[07:54] <mpt> kiko, so "angrykeyboarder" should be able to set the importance of Ubuntu bugs?
[07:54] <kiko> well
[07:54] <kiko> that's what I was asking
 seb128, mdz: should bugsquad be added as a member of ubuntu-bugs?
[07:55] <kiko> i.e.
 what is "ubuntu-bugs" supposed to be?
[07:55] <kiko> is everybody in bugsquad trusted enough to manage importance and milestones?
[07:55] <seb128> ubuntu-bugs == can edit importance and milestones? so no
[07:55] <kiko> seb128, ubuntu-bugs is the ubuntu bug contact -- essentially the group that is allowed to manage importance and milestones
[07:55] <mdz> that is the basic idea of bugsquad
[07:55] <seb128> I don't think everybody from that list should be able to edit a milestone
[07:56] <seb128> hum
[07:56] <bradb> seb128: milestone currently requires launchpad.Edit on the distro. so ubuntu drivers, basically.
[07:56] <mdz> they should be trusted enough to know that they shouldn't edit milestones, and should be knowledgeable enough to set importance
[07:56] <seb128> not sure I would give importance and milestone to the same people
[07:56] <mdz> if they don't have privileges for milestones, so much the beetter
[07:56] <mdz> wasn't I talking with someone about the ubuntu-bugs team recently? bradb?
[07:56] <seb128> importance for bugsquad is fine
[07:56] <bradb> yeah
[07:57] <seb128> I would let milestone to the main uploaders only (or a team near of that group)
[07:57] <kiko> mdz, so milestones should be restricted to drivers, and importance to -bugs?
[07:57] <mdz> kiko: that works for me
[07:57] <bradb> rougly: importance => bug contact or distro owner, milestone => distro owner
[07:57] <seb128> right
[07:57] <bradb> roughly, even
[07:57] <mdz> kiko: well, wait
[07:57] <seb128> who is "drivers" exactly?
[07:57] <mdz> kiko: milestones should be restricted to drivers, and importance to whatever the appropriate team is for QA
[07:58] <seb128> ok
[07:58] <seb128> so milestones for drivers and importance for bugsquad
[07:58] <mdz> that's sort of messy at the moment because of how ubuntu-bugs@lists is implemented
[07:58] <kiko> mdz, well, using the bug contact for that is very convenient for launchpad
[07:58] <kiko> because we don't need an extra database field for it
[07:58] <mdz> bradb: did we resolve that we should just make bugsquad a member of -bugs, or something like that?
[07:58] <mdz> kiko: OK then
[07:58] <kiko> mdz, well, I'm about to do that.
[07:58] <bradb> mdz: we resolved making qa a member of ubuntu-bugs.
[07:59] <kiko> bradb, QA /is/ a member of ubuntu-bugs but only sfllaw is a member :)
[07:59] <mdz> the ubuntu-qa team is already a member of ubuntu-bugs
[07:59] <bradb> kiko: i know. that came from that discussion.
[07:59] <seb128> ubuntu-qa looks like a dup of bugsquad
[07:59] <mdz> I think I may have created ubuntu-qa intending for it to become what bugsquad now is
[07:59] <mdz> but forgot to tell sfllaw about it
[07:59] <kiko> mdz, what should I do?
[07:59] <mpt> I'm just bemused that first we said "ability to prioritize bugs should be limited", but we're about to let netkid91 change importance
[08:00] <mpt> No offense to netkid91, whoever he/she is
[08:00] <mdz> kiko: I would like to get sfllaw into this conversation
[08:00] <seb128> creating a new issue would make no difference to that
[08:00] <seb128> bugsquad is people who have been approved by dholbach I think
[08:00] <mdz> mpt: dholbach and sfllaw are vetting membership in bugsquad
[08:00] <seb128> so you basically you say you don't trust dholbach for that job?
[08:00] <seb128> s#you##
[08:00] <mdz> and they know what they are doing
[08:01] <seb128> I think that too
[08:01] <mpt> seb128, no, I'm saying maybe dholbach didn't know that the team was going to be used for this purpose
[08:01] <seb128> maybe, maybe not
[08:01] <mdz> kiko: bugsquad should either be added to ubuntu-bugs or ubuntu-qa
[08:01] <kiko> mpt is hardly a more respectable nick than netkid91!
[08:01] <kiko> mdz, will do.
[08:01] <mdz> depending on whether sfllaw has plans for ubuntu-qa
[08:01] <mdz> kiko: if he doesn't, then ubuntu-qa should go away
[08:02] <mdz> 127 people in bugsquad! that is fantastic
[08:02] <kiko> Ubuntu BugSquad (bugsquad) was added as a member of Ubuntu Bugs.
[08:02] <kiko> seb128, try again :)
[08:03] <seb128> kiko: works fine, thank you ;)
[08:05] <kiko> enjoy
[08:09] <Ubugtu> Malone bug 49752 in malone "It should be possible to subscribe to an RSS feed of search results" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49752
[08:09] <bradb> inspired by a Dagwood submarine and two chocolate cookies
[08:12] <bradb> kiko: please to be giving my patch some love! i have a screenshot for you...(no running server, because i don't control the router here)
[08:18] <kiko> lifeless, are you around?
[08:19] <bradb> kiko: when you get a chance: http://www.flickr.com/photos/84096161@N00/167195885/
[08:20] <kiko> bradb, description seems strangely unrelated to attachment
[08:20] <kiko> hmmm
[08:21] <kiko> and the positioning of the patch checkbox seems to imply the description is a patch.. 
[08:21] <kiko> so kind of weird
[08:21] <kiko> I was wondering if a fieldset should be used to group attachment-related controls
[08:22] <bradb> kiko: i tried that already
[08:22] <bradb> kiko: it conflicts with the comment control
[08:22] <bradb> they look too similar
[08:23] <bradb> kiko: do you think people will get confused, and wonder if clicking patch means to suggest that their description is a patch?
[08:23] <kiko> no, I don't think that so much as I think the form looks awkward.
[08:23] <kiko> just that
[08:24] <bradb> kiko: how about we try it out?
[08:24] <kiko> bradb, can you should me the fieldset idea just so we can rule it out?
[08:25] <kiko> I was thinking something like
[08:26] <kiko> .---- [ ]  Include attachment ----------------.
[08:26] <kiko> | Description: [                           ]  |
[08:26] <kiko> |        File: [                ]  ( Browse ) |
[08:26] <kiko> |          [ ]  This attachment is a patch    |
[08:26] <kiko> '--------------------------------------------'
[08:26] <kiko> bradb, you get a lot of extra points if you detect that the patch is a patch instead of having the checkbutton
[08:26] <kiko> I think it's actually possible to do that but I do not know off-hand how
[08:26] <kiko> perhaps mdz does
[08:27] <kiko> SteveA, are you around?
[08:27] <mdz> kiko: it should be straightforward to guess whether it is a patch
[08:28] <bradb> kiko: a checkbox in the <legend> seems somewhat unexpected to me
[08:28] <kiko> mdz, yeah, but how?
[08:28] <kiko> bradb, give it a try.
[08:28] <kiko> I don't find it so unexpected
[08:28] <bradb> is it necessary?
[08:28] <kiko> yes.
[08:28] <kiko> it makes it clear it's optional
[08:28] <SteveA> kiko: yes, but just getting into some coding
[08:29] <kiko> SteveA, we have a problem in ##soyuz1.0 -- needs DBA assistance. do you have a suggested course of action?
[08:29] <kiko> bradb, well, not necessary, but I think it's worth a try.
[08:29] <kiko> if it looks kooky we can abort the idea of course
[08:29] <bradb> kiko: Attachment (optional) could do the same, without the extra click. Anyway, I'll try mocking it up again.
[08:30] <kiko> bradb, I don't like the word (optional)
[08:30] <kiko> salgado, what makes you think the commits mailing list is fixed?
[08:30] <mdz> kiko: the UI for displaying information about builds is a bit confusing
[08:30] <kiko> I got no email from there today
[08:31] <mdz> it tells us "date requested", "date built" and "duration"
[08:31] <salgado> kiko, Znarl said so
[08:31] <kiko> okaaay
[08:31] <mdz> a more appropriate label for "date built" would be "build started"
[08:31] <kiko> salgado, did you get any commits mail?
[08:31] <kiko> mdz, ah, nice hint
[08:31] <mdz> and it would be convenient if LP would show us the date when the build finished
[08:31] <salgado> kiko, no
[08:31] <mdz> that is information we often need, and currently we need to add the duration to the build start date to get it
[08:32] <kiko> mdz, should be easy. matsubara, can you check if mdz's request is filed in a bug and if not, file it? then assign to me.
[08:34] <sfllaw> mdz: dholbach and I were supposed to talk about ubuntu-qa at some point in time.
[08:34] <bradb> kiko: as another data point, here's what it looked like pre-mpt: http://www.flickr.com/photos/84096161@N00/167200548/
[08:35] <kiko> sfllaw, let me know of the outcome when you do? :)
[08:35] <kiko> bradb, having the attachment before the comment is not very nice!
[08:35] <mdz> kiko: who would I need to bribe to get the wiki change notifications to include a header that makes them filterable?
[08:35] <kiko> mdz, well, BjornT, mostly. he will be in paris btw. :)
[08:36] <kiko> salgado, can you poke matsubara?
[08:36] <bradb> kiko: i think attachments are the kind of thing people want to do as soon as they see the widget.
[08:36] <sfllaw> kiko: I'll note that down.
[08:36] <matsubara> kiko: checking
[08:36] <mdz> kiko: I'll just file the bug
[08:36] <mdz> nm
[08:36] <kiko> thanks matsubara 
[08:36] <bradb> e.g. gmail's attachment fu is before the body textarea
[08:36] <kiko> bradb, I think you are overstating the importance of attachments, but give my UI proposal a try and then we will decide.
[08:36] <bradb> i agree that it looks too important in that view though
[08:37] <mdz> sfllaw: unless there's a role for it which requires different launchpad permissions from bugsquad, I don't see that we need it
[08:38] <mdz> sfllaw: maybe once we have QA tools in launchpad, like the regression test tool we have talked about.  possibly not everyone in bugsquad should be able to drive that
[08:38] <mdz> mjg59: conclusion -> we need to bother BjornT
[08:38] <mdz> mjg59: I don't think he's around, so maybe file a bug?
[08:39] <mjg59> mdz: Ok
[08:39] <sfllaw> mdz: I see using ubuntu-qa merely as a permissions group.  BugSquad is the important thing to have membership in.
[08:39] <mdz> sfllaw: but ubuntu-qa and bugsquad have identical permissions
[08:39] <sfllaw> ?
[08:40] <sfllaw> Not from what I can tell.
[08:40] <mdz> unless ubuntu-qa is used elsewhere than as a member of ubuntu-bugs?
[08:40] <sfllaw> ubuntu-qa can twiddle Importance.
[08:40] <sfllaw> ubuntu-bugs isn't BugSquad.
[08:40] <mdz> but bugsquad is a member of ubuntu-bugs
[08:40] <mdz> should bugsquad really not be allowed to set importance?  I thought that was the point
[08:40] <sfllaw> It wasn't this morning?
[08:41] <sfllaw> This morning, only the TB was there.
[08:41] <mdz> correct, it changed (see scrollback)
[08:41] <bradb> kiko: btw, just to be clear, i mean that if somebody wants to attach a file, it's the kind of thing they'll want to do as soon as their brain spots the widget, not that Malone will experience a surge of attachments when the comment-while-attach goes live.
[08:41] <mdz> seb128 lost the ability to set importance
[08:41] <mdz> sfllaw: I thought bugsquad was people doing bug triage
[08:42] <sfllaw> BugSquad is a team of people who help with bugs.  Lots of them do triage, some fix bugs, some just hang out and need encouragement.
[08:43] <sfllaw> We had a very liberal acceptance policy.
[08:43] <sfllaw> Anyone who wanted access got it.
[08:43] <mdz> urgh
[08:43] <mdz> ok
[08:43] <mdz> so where do people go who we trust to set importance correctly?
[08:43] <kiko> bradb, I think that will be a large burden for people who just want to comment
[08:43] <sfllaw> mdz: bradb and I discussed this and decided on ubuntu-qa.
[08:44] <sfllaw> dholbach and I were going to go through the list of people and pull in the ones we knew did good work.
[08:44] <sfllaw> Then we'd train the rest of the people as they came through.
[08:44] <mdz> ok, that sounds fine then
[08:44] <sfllaw> But I'll pull in seb128 right now.
[08:44] <mdz> I've removed bugsquad from ubuntu-qa
[08:44] <bradb> kiko: if the bug page had some kind of reasonable way to tab through controls, i'd agree that it'd get in the way.
[08:44] <mdz> sfllaw: it was confusing because ubuntu-qa was basically empty
[08:44] <sfllaw> Sorry.
[08:44] <mdz> sfllaw: shouldn't -core-dev (and probably -dev) be members of -qa?
[08:44] <bradb> but whether they have to ignore it on top, or scroll past it to get to the Save Changes button, it seems a hindrance either way
[08:45] <sfllaw> mdz: Yes, I think so.
[08:45] <matsubara> mdz, kiko: does bug 30478 cover your request?
[08:45] <Ubugtu> Malone bug 30478 in soyuz "estimated build time should be displayed" [Wishlist,Confirmed]  http://launchpad.net/bugs/30478
[08:45] <sfllaw> If we trust them to upload, we certainly trust them with the BTS.
[08:45] <mdz> ok, they are now
[08:46] <mdz> matsubara: no, that's a different matter
[08:46] <kiko> matsubara, nope.
[08:46] <matsubara> kiko, mdz: ok, I'll file a new one then.
[08:46] <mpt> bradb, this is another symptom of the "not enough width" problem :-)
[08:47] <mpt> bradb, detecting whether it's a patch should be a "simple" matter of looking for --- and +++ near the start, right?
[08:47] <kiko> mpt, well, it doesn't need to be near the start, but yes generally
[08:47] <mpt> like, in the first ~6 lines
[08:47] <bradb> i'll try and do that...screenshot coming up shortly...
[08:48] <mpt> not that I'm an expert on diffs
[08:48] <sladen> mpt: patches frequently have alot of comment at the top.  especially @DPATCH@s
[08:48] <mpt> ah
[08:49] <mdz> sfllaw: I suggest we make ubuntu-bugs a closed team, since people aren't meant to join it
[08:50] <mdz> sfllaw: do you agree?
[08:50] <sladen> mpt: however, yes.  Looking for an all-text file (eg. parses as good UTF-8) and with  /^--- .*/\+\+\+ /  should be good enough in the first 2kB of the file
[08:50] <mdz> oh, I already did that some time ago
[08:50] <mdz> I just forgot to decline the most recent person who tried to join
[08:51] <sfllaw> mdz: I was going to tell you that.  :)
[08:52] <mpt> That's a grin-inducing error message
[08:52] <mpt> All error messages should be grin-inducing
[08:52] <mdz> sfllaw: so ubuntu-qa now owns ubuntu-bugs and is the only administrator, I removed techboard
[08:53] <sfllaw> Thanks.
[08:53] <sfllaw> I think.
[08:53] <mdz> wheels within wheels
[08:57] <matsubara> mdz, kiko: bug 49757
[08:57] <Ubugtu> Malone bug 49757 in soyuz "UI for displaying date information about builds is confusing" [Medium,Confirmed]  http://launchpad.net/bugs/49757
[08:57] <kiko> matsubara, thanks.
[08:59] <bradb> kiko, mpt: http://www.flickr.com/photos/84096161@N00/167207440/
[09:00] <bradb> I hope there is no pr0n
[09:00] <mdz> matsubara: thanks
[09:00] <Keybuk> mdz, sfllaw: where are teams members of ubuntu-bugs ?
[09:00] <kiko> bradb, I'd have the description before the file, personally
[09:00] <kiko> bradb, I think that looks quite good!
[09:00] <bradb> I think it looks pretty cool too.
[09:01] <bradb> I'm partial to desc after
[09:01] <bradb> kiko: notice there is no comment subject. what do you think of that?
[09:02] <kiko> bradb, I think you should probably cowboy that some other day, this may get us into enough trouble as it is :)
[09:02] <sfllaw> Keybuk: ?
[09:02] <sfllaw> Keybuk: I didn't parse that question properly.
[09:03] <Keybuk> https://launchpad.net/people/ubuntu-bugs
[09:03] <Keybuk> "These teams are members: ubuntu-core-dev, ubuntu-dev, etc."
[09:03] <Keybuk> why?  is ubuntu-bugs only exists as a gateway user for the mailing list
[09:04] <kiko> Keybuk, the bug contact is also the person who can change importance (along with the context owner)
[09:04] <bradb> kiko: even if it's only not being displayed? (i made no schema changes. it's still populating the subject with the default Re: $subject that, literally, 98.8% of comments have.)
[09:04] <Keybuk> kiko: I thought that's what the ubuntu-qa team was going to be for?
[09:04] <kiko> bradb, I'd leave it out because it's unrelated.
[09:05] <kiko> Keybuk, well, we need a way to discretely identify it against Distribution, and bugcontact makes implementation easier (and means one less control to configure), so they are conflated.
[09:05] <mdz> I thought we just agreed that ubuntu-bugs should only have ubuntu-qa as a member
[09:06] <mdz> and that -core-dev and -dev should be members of ubuntu-qa and not ubuntu-bugs
[09:06] <mdz> sfllaw: did we not?
[09:06] <sfllaw> mdz: We did.
[09:07] <kiko> bradb, I'd be happy to go with that UI (and if the patch-detection proves too flimsy I guess you can detect upon submission, but give it an honest shot :)
[09:07] <Keybuk> mdz: oh, this might be a UI issue then
[09:07] <Keybuk> yes, it's a UI issue
[09:07] <mdz> ohh, it is
[09:07] <mdz> you're right
[09:08] <Keybuk> how irrationally confusing
[09:08] <mdz> when I looked at it before, those teams weren't there
[09:08] <mdz> but after they were added to -qa, they are
[09:08] <mdz> yes, I don't think that display should recurse like that
[09:08] <Keybuk> aww
[09:08] <Keybuk> the publisher run just finished
[09:08] <mdz> kiko: what's your opinion?
[09:08] <Keybuk> 5 minutes over
[09:09] <kiko> let's see.
[09:09] <kiko> Keybuk, mdz, so you're saying that direct members and indirect members should be visually distinct in that listing, right?
[09:10] <Keybuk> kiko: yeah
[09:10] <kiko> matsubara, can you dig that bug up for me? I know it exists
[09:13] <bradb> kiko: I'm looking into detecting a patch now.
[09:14] <kiko> bradb, you da man!
[09:17] <AndreNoel> hello everyone
[09:21] <matsubara> kiko: maybe bug 48342
[09:21] <Ubugtu> Malone bug 48342 in launchpad "Team membership should state an indirect membership instead of just "you are not a mamber of this team."" [Low,Confirmed]  http://launchpad.net/bugs/48342
[09:21] <mdz> kiko: I'm saying that indirect members shouldn't even be listed
[09:21] <mdz> kiko: we don't do that for individuals, why for teams?
[09:21] <mdz> matsubara: not the same, but I've noticed that also
[09:22] <mdz> matsubara: we're talking about the 'relationship to other teams' list
[09:22] <AndreNoel> can i host a project in launchpad like i would do in the sourceforge?
[09:23] <kiko> mdz, hmmm.
[09:24] <kiko> AndreNoel, more or less yes, but there are some details that you'll need to consider.
[09:24] <kiko> first, we don't host mailing lists [yet] 
[09:24] <mpt> or Web pages
[09:24] <kiko> second, you need to use bzr as your revision control system.
[09:24] <kiko> third, we don't host web pages or FTP space.
[09:24] <kiko> that's it! 
[09:24] <AndreNoel> hmm
[09:24] <AndreNoel> ok
[09:30] <kiko> matsubara, does bug 42755 still occur?
[09:30] <kiko> ah sweet
[09:30] <kiko> it does!
[09:31] <matsubara> well, the rollout happened today.
[09:31] <kiko> OOPS-165C176
[09:31] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/165C176
[09:31] <kiko> I'll take a look at it
[09:45] <kiko> BjornT, ping?
[09:45] <BjornT> hi kiko 
[09:46] <kiko> BjornT, I am about to add a comment to bug 42755 that related to how we iterate over messages.
[09:46] <kiko> BjornT, is your comment-folding patch already done?
[09:46] <BjornT> kiko: yeah, it's done.
[09:47] <kiko> okay. I'll look into changing the workflow once that's landed then. it may involve some changes.. hmm.
[09:56] <kiko> +                        "You have been unsubscribed from bug %d. You can no "
[09:56] <kiko> +                        "longer have access to this private bug.") % bug.id)
[09:56] <kiko> bradb, can no longer have access? :)
[09:57] <bradb> er, s/have //
[09:57] <kiko> bradb, add a comment saying "# see render()" to initialize(self)
[09:57] <kiko> bradb, you no longer have access may be kinder 
[09:57] <kiko> but your call
[09:58] <bradb> sounds better, yeah
[09:58] <kiko> bradb, can we use some early returns to simplify that code?
[09:59] <kiko> bradb, it'd avoid the if/else nesting
[10:02] <kiko> bradb, if you wanna r=kiko in the next hour show me another diff now :)
[10:06] <bradb> just running the tests
[10:07] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filec1Vwru.html
[10:08] <kiko> bradb, add another two early returns and you're good.
[10:09] <bradb> that's nasty!
[10:09] <kiko> early returns? au contraire, they actually help your code 
[10:09] <kiko> long if/else branches are common sources of problems
[10:09] <kiko> in particular when you add code at the bottom of them
[10:09] <bradb> as are methods with five return points :)
[10:10] <kiko> no
[10:10] <kiko> if it's linear it's fine
[10:10] <kiko> I agree returning inside a deep branch is bad
[10:10] <kiko> but if XXX:
[10:10] <kiko> err, rather, bug:
[10:10] <kiko> if XXX:
[10:10] <kiko>    return
[10:10] <bradb> less a problem when not having to do our own memory management, but still nothing to brag about
[10:10] <kiko> if YYY:
[10:10] <kiko>    return
[10:10] <kiko> if ZZZ:
[10:10] <kiko>   return
[10:10] <kiko> is fine
[10:10] <kiko> s/bug/but above and you see what I mean
[10:11] <kiko> bradb, also
[10:11] <kiko> if not X == Y 
[10:11] <kiko> should become
[10:11] <kiko> if X != Y
[10:11] <bradb> right. my brain's in bzr smash mode atm, i think.
[10:12] <kiko> bradb, note /also/ that another way of avoiding those nested ifs
[10:12] <kiko> without using early returns
[10:12] <kiko> would be doing person = subscription_person and notice = X inside the individual branches and hand that off to another method
[10:12] <bradb> right
[10:13] <bradb> i'm going to move the subscription code to a different class in my next landing.
[10:13] <bradb> BugTaskView has gone hotel staffer
[10:13] <kiko> I don't suggest you do that now of course just a general suggestion
[10:14] <bradb> i was planning to refactor this mess next landing one way or the other
[10:18] <bradb> is this what you meant? https://chinstrap.ubuntu.com/~dsilvers/paste/filefjlK5N.html
[10:18] <bradb> kiko: ^^
[10:19] <kiko> bradb, yes. but now that I read that code I am finding this very strange.
[10:19] <kiko> +        if 'subscribe' in self.request.form:
[10:19] <kiko> shouldn't that be the very first thing after the POST check?
[10:19] <kiko> bradb, and ideally, handled by a separate method?
[10:19] <kiko> how about having _handleSubscribe() and _handleUnsubscribe() methods?
[10:20] <kiko> i.e.
[10:20] <bradb> kiko: can i refactor this in my next landing? it'll end up looking very different.
[10:20] <kiko> bradb, very different? why?
[10:20] <kiko> I'd rather you refactor as you went
[10:20] <kiko> that's a better workflow.
[10:20] <bradb> i agree
[10:20] <bradb> but i don't agree that it makes sense to refactor as part of this merge
[10:21] <kiko> well
[10:21] <kiko> the problem is going back to refactor
[10:21] <kiko> which we rarely do
[10:21] <kiko> so I am of the principle that if you are going to make things more complex
[10:21] <kiko> you refactor as you do it.
[10:21] <kiko> now
[10:21] <bradb> my next landing is to refactor BugTaskView
[10:21] <kiko> if you want to /just/ do my suggestion
[10:21] <kiko> which is:
[10:21] <kiko> +        if 'subscribe' in self.request.form:
[10:22] <kiko> +               self._handleSubscribe()
[10:22] <kiko> +        else
[10:22] <kiko> +               self._handleUnSubscribe()
[10:22] <kiko> I think that's cheaper than whatever full refactoring you are going to do
[10:22] <kiko> and it is also "more correct" than the current code
[10:22] <bradb> cheaper, but less useful, IMHO, because BugTaskView shouldn't be handling subscription at all.
[10:23] <bradb> that the subscription pages post to this form at all is completely messed up
[10:23] <bradb> posts should be handled by GFV's
[10:23] <kiko> bradb, you can move that code out later. it won't matter -- the semantics that the code above embodies will still be preserved.
[10:24] <bradb> ok. i'll refactor it when i get home. i have to run to the bank, which closes in 35 mins, to pay a tax installment. bbiab.
[10:24] <kiko> bradb, okay, see you in an hour.
[10:24] <bradb> later
[10:39] <ddaa> does anyone knows of an easy, secure, non-nonsense tutorial for ssh public keys?
[10:40] <ddaa> not sure if those requirements are not contradictory, but I need something good to point at from the blog article for launchpad bzr hosting I'm writing.
[10:57] <mdke> ddaa: there is some material on the Ubuntu wiki that might help, or you could improve it
[10:57] <mdke> https://wiki.ubuntu.com/SSHHowto
[10:57] <mdke> https://wiki.ubuntu.com/AdvancedOpenSSH
[10:59] <ddaa> mdke: thank you
[11:59] <bradb> kiko: this subscriptions code does need to be desparately rewritten
[12:00] <bradb> e.g. there are *radio buttons* (!) for "Subscribe me to this bug" and "Unsubscribe $some_team_im_a_member_of"
[12:00] <bradb> see also: desperately
[12:01] <mpt> !