[01:25] <dilys> Merge to devel/launchpad/: [trivial]  fix InternalHTTPLayer (unbreaks supermirror-pull-list.txt) (r1812: David Allouche)
[01:59] <Seveas> doesn't basic authentication work anymore?
[02:32] <lifeless> ddaa: you are seeing the canonical revision history now
[03:00] <mpt> Goooooooooooooooooooooooood afternoon Launchpadders!
[06:30] <stub> lifeless: So why did David's patch land with a rev no a few thousand less than expected, and should I be scared since he needs it cherry picked into production?
[06:43] <lifeless> stub: bzr normalises the revision history now.
[06:43] <lifeless> stub: let me check
[06:49] <lifeless> stub: looks ok so far
[06:49] <lifeless> checking the way-old-stuff now
[06:50] <stub> Ok. So it is safe for people to merge as normal as long as they use new-revnos where necessary.
[06:50] <stub> Is the history normalization a one off, or will the numbers continue to change on occasion?
[06:57] <lifeless> at the moment it happens during push and pull.
[06:58] <lifeless> revno: 1 looks correct.
[07:01] <lifeless> it will probably nbounce around a bit when we merge in all the history
[07:02] <stub> This change will make documenting cherry picks difficult - saying 'Merge r666 from foo' is no longer useful. A unique, unchanging id might be necessary to support the workflow (?).
[07:04] <stub> Although 'Merge stuart.bishop@canonical.com-DEADBEEF123412349876' would be a bit sucky ;)
[07:06] <stub> And hopefully revnos won't change between a cherry pick request being requested and being done (or for that matter, between me entering a merge command and the merge actually starting)
[07:08] <stub> Heh.... don't push bound branches ;)
[07:08] <stub> 11:57:56~/src/dropbear $ bzr commit
[07:08] <stub> bzr: ERROR: Cannot commit to branch BzrBranch5(u'/home/stub/src/dropbear/'). It is bound to BzrBranch5('sftp://goanna/home/z/zen/archives/dns/dropbear/'), which is bound to sftp://goanna/home/z/zen/archives/dns/dropbear/.
[07:13] <stub> mpt: Create a fresh branch from rocketfuel-built/launchpad and merge your changes into that. It is a lot faster than the other way around if you won't need to revert individual commits from before.
[07:27] <stub> bug 40486
[07:27] <Ubugtu> Malone bug 40486 in bzr "normalizing history causes cherry picking workflow problems" [Normal,Unconfirmed]  http://launchpad.net/bugs/40486
[07:28] <lifeless> stub: log --show-ids
[07:28] <lifeless> stub: you rsync pushed didn't you.
[07:29] <stub> The bound branch? Yes. I'll add that to the bug report.
[07:30] <lifeless> ah, I know why the history has jumped around
[07:30] <lifeless> the parent-ids are not ordered properly for some revisions
[07:31] <lifeless> I'll figure it out, then they will stabilise again
[07:32] <lifeless> stub: revids have never been useful : bzr supports 'uncommit'
[07:32] <jamesh> mpt: "pull --overwrite" into a new rocketfuel branch should also avoid the reconcile
[07:32] <lifeless> jamesh: nope
[07:32] <jamesh> lifeless: oh?
[07:32] <lifeless> pull --overwrite will still reconcile
[07:32] <stub> Yes. I'm not sure of the best solution, but it needs to be thought about when bzr wants to support cherry picking properly
[07:33] <jamesh> lifeless: I thought merge and pull pulled new information into the repository in essentially the same way
[07:33] <lifeless> jamesh: they do
[07:34] <lifeless> jamesh: thats why pull --overwrite will do a reconcile
[07:34] <stub> uncommit you are shooting yourself in the foot. revnos changing for reasons not your fault could be thought of as bzr shooting you in the foot ;)
[07:35] <jamesh> lifeless: stub was suggesting creating a new branch from rocketfuel-built and then merging into that.  I was suggesting creating a new branch from rocketfuel-built and then using "pull --overwrite" to pull data into it
[07:35] <jamesh> lifeless: I'd expect either both to be fast or both to be slow
[07:35] <lifeless> jamesh: both the suggested merge and pull will trigger a reconcile or possibly even global reweaving
[07:35] <lifeless> because the databases are inconsistent with each other
[07:36] <jamesh> okay
[07:40] <stub> The merge approach worked for myself and carlos, saving a day or threes merge time
[07:41] <jamesh> I guess the reconcile is quicker in one direction than the other
[07:42] <stub> lifeless: Something else is odd. I've got a cherry pick request for r1812 from ddaa, but it doesn't exist in rocketfuel/launchpad/devel on balleny
[07:42] <stub> (unless the log output is broken)
[07:43] <stub> lifeless: Emails were sent out about that rev
[07:44] <lifeless> stub: yes I'm looking into the issue
[07:44] <lifeless> fwiw
[07:45] <stub> ok. I'll grab some lunch. Worst case I'll get ddaa to give me a diff when he is online.
[07:45] <lifeless> hmm, not sure where his commit hath gone.
[07:46] <stub> pqm is still busy doing stuff
[07:47] <stub> webui says it is still dealing with ddaa's patch
[07:47] <lifeless> heh
[07:47] <lifeless> indeed it is
[07:47] <lifeless> lets see
[07:48] <stub> 1.6gb resident.... regression?
[07:48] <lifeless> nope, thats the knit conversion
[07:48] <lifeless> needs some tuning
[07:49] <lifeless> 30129 is pqm
[07:49] <stub> We can do it on carbon if ram is a problem ;)
[07:49] <lifeless> whats carbon ?
[07:49] <stub> jubany's sister
[07:49] <stub> 32GB ram
[07:49] <stub> Although I think elmo has stolen it for the beta release
[07:50] <lifeless> nice
[07:50] <lifeless> test database server?
[07:50] <stub> (hell - we could use jubany. I havn't seen it go about 10% CPU yet)
[07:50] <stub> lifeless: I want to set it up as a replica. I'll be testing with staging first.
[07:51] <lifeless> ah, f'course
[07:54] <stub> heh... emperor is idle :)
[07:54] <stub> New pqm box?
[07:54] <lifeless> nah, overkill. want that for playing quake on 
[07:54] <stub> (actually... probably slower due to slower cpus...)
[07:55] <lifeless> ah, fckin, bzr had a read lock on the launchpad branch. hang on
[08:05] <lifeless> dang 
[08:05] <lifeless> I killed the wrong process. ddaa's patch needs to go through again
[08:05] <stub> sftp://chinstrap.ubuntu.com/home/warthogs/archives/david/launchpad//smallfixes/
[08:06] <stub> You want to send it through?
[08:06] <lifeless> yup
[08:21] <lifeless> stub: when you get back, can you please update the related product for https://launchpad.net/bounties/breezecom-pro-11-sa-pcr/+admin to be linux-source/linux/something like that ?
[08:21] <mpool> ubuntu, anyhow
[08:38] <lifeless> mpt_: how does one add milestones ?
[08:44] <jamesh> lifeless: productseries page
[08:44] <jamesh> "add milestone" in overview menu
[08:44] <lifeless> yeah, just found it
[08:47] <dilys> Merge to devel/launchpad/: [trivial]  fix InternalHTTPLayer (unbreaks supermirror-pull-list.txt) (r1812: David Allouche)
[08:47] <mpool> that is a bit hard to discover
[08:47] <lifeless> 'bit' :)
[08:48] <mpool> is there a public faq?
[08:48] <stub> 0 dollar bounty? Hmm...
[08:51] <mpool> about how to use launchpad, e.g. "how the hell do i add a milestone"
[08:51] <jamesh> mpool: there is a link down the bottom of every page in launchpad, but it is currently cut off due to a zope bug
[08:51] <mpool> :-)
[08:51] <jamesh> mpool: https://launchpad.net/faq
[08:54] <stub> mpool: Ideally stuff that isn't discoverable should be opened as bugs - mpt's goal is we shouldn't need an faq or manual at all.
[08:55] <stub> (although faq is good until we get there...)
[08:55] <mpool> even the human nipple has an faq :-)
[08:56] <mpool> but it's a good goal
[08:56] <stub> The human nipple is put to non-obvious uses though, so that is understandable ;)
[08:56] <mpool> jamesh: thanks; i assume that's only editable by developers?
[08:56] <jamesh> mpool: yeah.
[08:56] <jamesh> it is a page template in the launchpad tree
[08:59] <carlos> morning
[09:04] <lifeless> which of severity and priority did we keep ?
[09:05] <mpool> i added bug #40497
[09:05] <Ubugtu> Malone bug 40497 in launchpad "very hard to find out how to add a milestone" [Normal,Unconfirmed]  http://launchpad.net/bugs/40497
[09:42] <SteveA> mpt_: hello
[09:52] <lifeless> bug *
[09:52] <lifeless> mpt__: stevea says hello to mpt_ 
[10:00] <carlos> lifeless: is there anything wrong with rocketfuel's launchpad?
[10:00] <carlos> lifeless: lattest commits have lower revision numbers than yesterday
[10:00] <lifeless> carlos: yes, thats a quirk in bzr I'm looking into
[10:00] <carlos> ok
[10:01] <lifeless> we normalised the revision numbers , its nothing that will break you
[10:01] <lifeless> no data loss
[10:25] <carlos> ok
[10:27] <mpt__> mpool, where's the Nipple FAQ? :-)
[10:27] <mpool> why do you need it? :-)
[10:27] <mpt> I'm just questioning your assertion that it exists
[10:27] <mpool> Results 1 - 10 of about 3,250,000 for nipple faq
[10:28] <mpt> logical fallacy: argument from google
[10:28] <SteveA> mpt: hello
[10:28] <mpt> I don't mind the existence of a FAQ, but it's *completely* backwards that it should be developers maintaining it
[10:28] <mpool> i think this is the canonical faq: http://www.straightdope.com/classics/a1_093.html
[10:28] <mpt> hi SteveA 
[10:28] <mpool> hi SteveA
[10:29] <SteveA> mpt: i /msged you as mpt_
[10:29] <SteveA> i'll do it again
[10:29] <SteveA> hi mpool 
[10:31] <lifeless> SteveA: evil evil man
[10:46] <SteveA> jamesh: around?
[11:04] <jamesh> SteveA: yeah
[11:04] <SteveA> hi jamesh 
[11:05] <SteveA> do you have time for a skype call?
[11:05] <jamesh> okay.  I'll fire it up
[11:05] <SteveA> i'd like to catch up with what's been happening, interesting technical issues etc.
[11:23] <jamesh> SteveA: https://launchpad.net/products/launchpad/+spec/error-report-management-for-scripts
[11:39] <stub> jamesh: Are you replacing the existing log-exceptions-to-the-librarian code?
[11:54] <SteveA> stub: right now, that's still a braindump
[11:54] <SteveA> james and i were going to talk about what to do with it sometime next week
[11:55] <jamesh> stub: the plan is to provide some infrastructure for scripts to be able to generate oops reports.  It would be a replacement for the log exceptions to librarian code in the scripts that used it
[11:55] <stub> It was flagged as started I thought
[11:55] <SteveA> i'd like all our warnings, soft timeouts, errors and stuff to come into the same oops infrastructure
[11:55] <SteveA> so that we can plug it into the same QA processes
[11:55] <jamesh> I didn't set it to started
[11:56] <stub> The librarian stuff was just a hack anyway to save my mailbox from rosetta's DOS attacks
[12:34] <Keybuk> Launchpad has suddenly lost its monospace-ness for the text entry box
[12:34] <Keybuk> is that a style bug, or a firefox bug?
[12:39] <Keybuk>   font-family: sans-serif;
[12:39] <Keybuk>   font-family: caption;
[12:39] <Keybuk> iz style bug
[12:39] <mpt> Keybuk, suddenly? It's been like that for six months or so
[12:39] <BjornT> fwiw, in Opera the text entry boxes still use a monospace font
[12:39] <Keybuk> mpt: new firefox or pango upload may have changed the font that it ended up with
[12:40] <Keybuk> having two font-family declarations is a bug though, no?
[12:40] <mpt> No, because some browsers don't support "caption"
[12:40] <mpt> (which is CSS2-ese for "whatever font your native GUI uses")
[12:41] <mpt> So the idea is to use caption if the browser knows how to implement it, or sans-serif if it doesn't
[12:41] <Keybuk> it's picked a serif font which is nothing like what my GUI uses
[12:41] <mpt> so it does
[12:41] <mpt> That would be a bug in Firefox, then
[12:41] <stub> bug comments are having whitespace chomped too
[12:42] <mpt> hmmmmm
[12:42] <mpt> data:text/html,<html><p style="font: caption;">Foo</html> works as expected
[12:42] <mpt> so, it's a Launchpad bug
[12:44] <mpt> no, DOM Inspector says "caption" for Computed Style
[12:44] <mpt> so it's a Firefox bug
[12:50] <mpt> The CSS2 UI module is the embodiment of dodginess
[12:57] <carlos> stub: hi, did you executed the migration script with the r1811 (was r3488) cherrypick ?
[01:06] <mpool> i just had a nice session with malone - thanks to all responsible
[01:06] <mpool> and goodnight
[01:09] <mpool> on which note Epiphany finally collapses...
[01:12] <lifeless> mpt: discussioon in #ubuntu-devel about firefox and images :0
[01:14] <mdz> kiko: X-Launchpad-Bug seems to contain priority, but not the more useful severity.  I assume this will be a non-issue when priority goes away?
[01:23] <SteveA> mpt: you should be able to write to ~stevea/public_html/menus-plan.txt on people.ubuntu.com
[01:23] <SteveA> please check this
[01:24] <SteveA> kiko is at FISL, so may not read irc today
[01:24] <SteveA> mdz: we should have importance there, and we should be doing that shortly.
[01:27] <mdz> oh, hi SteveA
[01:27] <mdz> I am unaccustomed to overlapping hours with you ;-)
[01:49] <Keybuk> hmm
[01:49] <Keybuk> why is the Wiki so much slower to save again?
[02:01] <mpt> mdz, dang, I was lazy and just deleted priority ... I'll add importance
[02:01] <lifeless> dude, land what you have !
[02:01] <lifeless> then add another much smaller patch for incremental tweaks
[02:05] <mdz> mpt: I agree with lifeless; it's not critical for landing it
[02:08] <mpt> ok
[02:08] <mpt> for example, the bug icons are still be colored by priority, which will need changing, but I've XXXed that
[02:09] <lifeless> mpt: release early, release often
[02:09] <mdz> mpt: have you given a heads-up to the distro team about this change?
[02:09] <mdz> given it's heading for production
[02:10] <mdz> in fact, malone is so visible that the larger community should probably be notified
[02:14] <mpt> mdz, that's on my to-do list as soon as the branch lands in rocketfuel
[02:14] <mpt> which will give people about a week's notice
[02:14] <mpt> furthermore, if people try to use priority or severity by e-mail, they get an explanatory message about importance and its values
[02:14] <mpt> in reponse.
[02:14] <mpt> +s
[02:15] <lifeless> mpt: why has it not landed though? you got +1.
[02:15] <SteveA> email about "importance and values"
[02:15] <SteveA> sounds more like a lecture in morals
[02:16] <mpt> lifeless, because many new occurrences of severity and priority were introduced recently and I haven't finished fixing them all
[02:17] <mpt> that's why I was considering getting another review, not just because of X-Launchpad-Bug!
[02:17] <BjornT> SteveA: care to take a look at https://chinstrap.ubuntu.com/~dsilvers/paste/file8q6KsL.html? it fixes bug 40329
[02:17] <Ubugtu> Malone bug 40329 in launchpad "The wrong encoding is chosen if '*' is in the Accept-Charset header, but 'utf-8' isn't" [Normal,In progress]  http://launchpad.net/bugs/40329
[02:18] <SteveA> BjornT: yes, and it is still the correct URL even with the ? on the end :-)
[02:18] <lifeless> mpt: ah. yes, ok.
[02:19] <lifeless> SteveA: btw, us leaving priority in the database and code really concerns me. I understand mark has set a mandate for it, but I'd like us to consider putting some policy in place
[02:19] <SteveA> leaving priority in there was news to me when i glanced at the spec today
[02:20] <SteveA> i don't see a point in the data remaining, because it will be out of date in a short time
[02:20] <SteveA> and i don't see a point in the code remaining, as it will be untested, and unused
[02:20] <SteveA> and so will just be decoy code
[02:23] <lifeless> these are all thngs that concern me
[02:24] <lifeless> I don't consider my role inside the lp team sufficient to headbutt Mark on this, not after it was apparently decided previously.
[02:24] <lifeless> thats why I'm telling you;)
[02:24] <Max_Littlemore> Hiya, just joined due to a slashdot earlier. I'm really interested in RT audio and have a few ideas (although nothing prepared).
[02:25] <Max_Littlemore> ... sorry didn't mean to hit enter yet.... :-[ newbie
[02:26] <lifeless> Max_Littlemore: rt audio ?
[02:26] <mpt> Max_Littlemore, if you mean you're interested in real-time audio development for Ubuntu, try #ubuntu-devel
[02:26] <mpt> This channel is about Launchpad
[02:29] <Max_Littlemore> What is LaunchPad? I use sarge at home and wXP at work... thanks mpt, like i said, i got this from trying to join a furum that wa linked to from /. - yes rt audio - let us all out mac the mac!
[02:30] <SteveA> lifeless: check your email.
[02:30] <lifeless> Re: Bug#363598: udev should conflict with ifrename ?
[02:31] <lifeless> danke
[02:32] <mpt> and I was halfway through explaining what Launchpad was, too
[02:36] <jordi> https://launchpad.net/products/rosetta/+bug/40550
[02:36] <Ubugtu> Malone bug 40550 in rosetta "Further filtering options for the Queue" [Normal,Unconfirmed]  
[02:36] <jordi> cothere
[02:36] <jordi> carlos: there
[02:37] <carlos> jordi: cool, thanks
[02:44] <SteveA> BjornT: looks good
[02:45] <BjornT> thanks
[02:45] <SteveA> BjornT: my only comment, kinda hypothetical, is that we might have any preferred charset, not only utf-8
[02:45] <SteveA> i can imagine favouring utf-16 for sites based in the east, for example
[02:46] <SteveA> but then again, maybe yagni
[02:48] <BjornT> SteveA: i know. the adapter that i modified does prefer utf-8, so i'd say my fix is correct. i would say that the current design as how the encoding is chosen is kind of broken, but it works for most cases, and i don't feel like spending time on that.
[02:48] <SteveA> fine
[06:43] <carlos> have a good weekend!!! see you on Tuesday!!
[06:56] <ohoel> hm, I bet this is the right place to ask; is there an ETA on fresh langpacks hitting the archives?
[07:01] <WaterSevenUb> (Ideally that should be calendarized even during this cycle while monthly or weekly langpacks are not streamlined.... curious about the answer too anyway)
[07:02] <ohoel> until search hits rosetta, it's hard to verify release-ready translations without regular updates
[07:02] <WaterSevenUb> yeah, I totally agree.
[07:03] <ohoel> I know I've got the gnome ones right, but rosetta tends to introduce some "original" translations to replace mine ;)
[07:04] <ohoel> or rather, rosetta users tend to
[07:04] <WaterSevenUb> yes, true :)
[07:05] <WaterSevenUb> regular updates are great for testing.
[07:05] <ohoel> mmh, I almost feel like a troll atm :p
[08:14] <bradb> stub: ping
[08:15] <bradb> stub: just double-checking: bug searches not matching on terms like "foo.bar" is bug 29227, right?
[08:15] <Ubugtu> Malone bug 29227 in malone "Searching for "pmu" doesn't find "/dev/pmu"" [Critical,In progress]  http://launchpad.net/bugs/29227
[08:26] <SteveA> bradb: hello
[08:26] <bradb> SteveA: hi
[08:26] <SteveA> bradb: i don't think stub will be around until next week
[08:26] <SteveA> i wanted to ask, how's the "priority + severity -> importance" branch going?
[08:26] <bradb> SteveA: you'd have to ask mpt
[08:26] <SteveA> has it landed yet?  i gather mpt is working on at least part of it
[08:26] <SteveA> okay, i'll mail mpt
[09:01] <bradb> salgado: I responded to both of your code reviews today. Might you have time to take a look?
[09:01] <ddaa> is that a problem with me, or did other people notice that rocketfuel-built is no longer updated?
[09:02] <ddaa> anyone knows what's going on?
[09:07] <mdke> i just tried to download a source tarball from launchpad for ubuntu-docs version 6.04.7
[09:07] <mdke> I downloaded and untarred it, and found that it was 6.04.6
[09:08] <mdke> presumably because .7 hasn't built yet, or been published or something
[09:08] <mdke> is this a known bug?
[09:11] <mdke> oh no, perhaps it is .7, the tarred folder is just called .6
[09:15] <nick1> hi, i have a question, on a URL such as https://launchpad.net/specs, what does the blue (i) mean on the second specification down?
[09:17] <nick1> nevermind, it denotes it as informational only, it doesn't say
[09:17] <SteveA> nick1: the (i) Undefined
[09:17] <kiko_> hello there
[09:17] <nick1> oh
[09:17] <nick1> thanks SteveA
[09:17] <SteveA> is saying that the spec isn't linked to a full specification
[09:18] <SteveA> that part of the UI could be improved to say that explicitly
[09:18] <SteveA> so i'm not surprised it was confusing
[09:18] <SteveA> hmm
[09:18] <nick1> okay, i'll file a bug
[09:18] <SteveA> or maybe i'm wrong
[09:18] <SteveA> because some that do link to specs also have (i) undefined
[09:18] <SteveA> nick1: please file a bug to say that it is confusing
[09:18] <SteveA> on the "blueprint" product
[09:19] <SteveA> and we'll check the source code and unconfuse it
[09:19] <SteveA> thanks!
[09:19] <nick1> i think it means informational only, cos i remember ticking that box, thanks, i will file a bug
[09:19] <SteveA> i guess it is the priority
[09:19] <SteveA> if you look at the spec's page, then the priority says "undefined"
[09:20] <SteveA> the (i) might mean "informational" as you point out
[09:20] <SteveA> so, i guess i was wrong, the (i) and the "undefined" aren't linked -- they are two distinct pieces of information
[09:20] <SteveA> if the (i) had a nice pop-up image title, that would help
[09:21] <nick1> yeah
[09:21] <nick1> okay, im filing it now
[09:27] <nick1> SteveA: https://launchpad.net/products/blueprint/+bug/40631
[09:27] <Ubugtu> Malone bug 40631 in blueprint "What does the ( i ) mean" [Normal,Unconfirmed]  
[09:27] <nick1> wow
[09:27] <SteveA> thanks
[09:27] <SteveA> Seveas wrote Ubugtu.
[09:28] <nick1> its pretty cool
[09:28] <nick1> a good idea
[09:30] <SteveA> nick1: i assigned mpt to fix it
[09:30] <nick1> okay thanks
[09:31] <nick1> i'v not used launchpad in a while, its the 3rd one i'v reported today :/
[09:32] <nick1> infact, maybe all images should have alt/titles, its in the W3C
[09:36] <bradb> salgado: What do you mean by "use another binarypackagename,
[09:36] <bradb> workarounding the bug."?
[09:37] <bradb> BP is added to the description, and the description is currently not properly searched for search terms with dots in them, e.g. "package-name.1.2.3" won't find bugs that have that term in the description, because of the bug assigned to stub.
[09:38] <salgado> bradb, replace 'linux-2.6.12' on "'field.packagename': 'linux-2.6.12'" with another packagename that doesn't contain dots
[09:39] <bradb> ah, i see
[09:45] <bradb> salgado: So, I specifically chose that package because it conveniently has a bin pkg name different from its src pkg name, so that I can be sure Malone is putting the right values in the right places. Since the code in question's only purpose is to get me the BugTask I just created (i.e. it's not testing the search, because that's tested elsewhere), how about just:
[09:45] <bradb>     >>> search_params = BugTaskSearchParams(user=current_user)
[09:45] <bradb>     >>> latest_ubuntu_bugtask = ubuntu.searchTasks(
[09:45] <bradb> ?
[09:45] <bradb>     ...     search_params)[-1] 
[09:47] <bradb> oh, with an orderby="id" thrown in for good measure.
[09:47] <salgado> bradb, the reason why I asked for that change was to make sure a search for the binarypackagename would return that bugtask
[09:50] <bradb> Hm, the only way to usefully do that, I think, is to add more publishing records to soyuz. :/
[09:50] <bradb> And more SPs/BPs into the system, with SPs that have BPs that have names different from their SP.
[09:52] <bradb> Because the search matches on targetname already (as tested in bugtask.txt), so if targetname == bp name, nothing is really being tested.
[09:54] <bradb> It's just a word plopped into the description though, and we already test that it is being plopped into the description, and we already test searching the description, IYSWIM
[09:54] <salgado> I see
[09:55] <salgado> I know it's not trivial to add new sampledata on that area, so I think you can merge it
[09:55] <salgado> but leave the search_params as it is
[09:55] <bradb> ok, will do, thanks
[09:56] <bradb> next thing I have to do here is email stub about the data migration we'll need to do now that BP is getting blow away, but I wanted to have the r= before going to that step
[10:30] <ddaa> SteveA: ping
[10:30] <SteveA> ddaa: hi
[10:31] <doko> good evening
[10:31] <siretart> hi doko 
[10:31] <doko> are build logs available outside the librarian, so that I can grep over all build logs?
[10:32] <bradb> salgado: Think you'll have a chance to respond to the other review response today?
[10:38] <salgado> bradb, I don't think so. I'm leaving soon and have some stuff to finish here.  I'll answer it on monday for sure
[10:40] <bradb> ok, no worries, thanks
[10:49] <sits> hi
[10:50] <sits> I have a couple of launchpad observations
[10:51] <bradb> sits: Not many devs are around right now.
[10:51] <sits> I know talk is cheap but I'm hoping to offer some partial solutions
[10:51] <bradb> I'd suggest mailing launchpad-users@
[10:51] <sits> mmm but it's not on GMANE at the moment
[10:52] <sits> and following lists on webmail is painful
[10:52] <bradb> or you can use malone to file your issues as bug reports.
[10:53] <sits> oh I'm well aware of malone
[10:53] <sits> that's what I was going to talk about
[10:53] <bradb> oh, well, in that case, I'm around, so you're in luck :P
[10:54] <sits> around 5-6 years ago I spent a lot of time using the Mozilla bugzilla
[10:54] <sits> (about the same time mpt was active there actually)
[10:54] <sits> at some point, someone introduced the unconfirmed flag
[10:54] <sits> now, from a developer perspective the unconfirmed flag is fantastic on a bug
[10:55] <sits> it means you can avoid looking at potentially spurious bugs
[10:55] <sits> unfortunately there's another side
[10:55] <sits> it means someone has to look at a bug and confirm it
[10:56] <sits> in the mozilla bugzilla it wasn't long before unconfirmed bugs ran rampant, outpacing the number of people looking at them
[10:56] <sits> frivolous bugs started turning up to
[10:57] <sits> vague things that couldn't easily be dismissed, requests for outlandish features
[10:57] <sits> there were bug drives to get the unconfirmed count down and these would work for a time but one off heroics don't last long
[10:58] <sits> anyway I think the unconfirmed status though good for devs is bad for the bug system unless you have some amazingly scalable frontline support staff willing to soak up the flack
[10:59] <sits> confirming bugs is boring repetitive thankless work and as your work gains popularity you only need more people to do it
[10:59] <sits> Reports are often awful
[11:00] <bradb> what's the alternative to bug triaging?
[11:00] <sits> bradb: hey I'm not finished yet
[11:00] <sits> bradb: but that's a good question which I don't have a good answer to. I don't think there is an alternative per se
[11:01] <sits> I think we need to leverage more of the people filing bugs and turn them into front line support people
[11:02] <sits> of course that's easy to say and difficult to do
[11:02] <bradb> sits: I think a lot of OSS projects attempt to do that. /me digs up a recent bug mpt filed
[11:02] <sits> bradb: oh ok...
[11:03] <sits> cor blimey
[11:03] <sits> mpt certainly knows how to file the bugs
[11:03] <bradb> bug 37926
[11:03] <Ubugtu> Malone bug 37926 in malone "Manage expectations about newly-reported bugs" [Normal,Confirmed]  http://launchpad.net/bugs/37926
[11:03] <bradb> it's a subtle way of encouraging participation
[11:04] <sits> hmm low tech but subtle
[11:04] <sits> that's good
[11:05] <sits> dunno that it's wise to put an upper limit on there though
[11:05] <bradb> karma was also invented for this reason
[11:05] <sits> hmm
[11:05] <bradb> to reward people who contribute
[11:05] <sits> now that's an interesting one
[11:05] <sits> I have some karma but I don't know what it means
[11:06] <sits> do I have a lot or a little?
[11:06] <sits> can I use it to buy stuff?
[11:06] <sits> does it let me talk louder?
[11:06] <sits> does anyone besides me ever check it?
[11:06] <bradb> sits: Karma is still pretty vague.
[11:06] <sits> are there acts that decrease it?
[11:06] <sits> bradb: oh ok
[11:07] <sits> I mean one simple but offencive trick is to make a karma leaderboard
[11:07] <sits> this suckers the competitive into doing more
[11:07] <bradb> sits: we have one, actually
[11:08] <sits> once again I feel stupid for not knowing
[11:08] <bradb> sits: https://launchpad.net/
[11:08] <bradb> "Top contributors:"
[11:08] <sits> bradb: you certainly have a lot of patience
[11:08] <bradb> sits: Don't feel bad. Lots of people new and more experienced with LP have a hard time working out the UI.
[11:08] <sits> is there a longer one?
[11:09] <bradb> not that I'm aware of
[11:09] <sits> hmm
[11:09] <bradb> because the numbers have been a bit too silly to get too serious about it yet
[11:09] <sits> it's kind of disheartening to see someone with 100 times more karma. It's a big target to reach for
[11:10] <sits> well maybe 50
[11:10] <sits> I guess one thing I thought was that you could use your karma standing to draw more attention to your bugs
[11:11] <sits> this was based upon an idea that you submitted your machine's hardware
[11:11] <sits> so launchpad could periodically churn out 10 bugs that you could try and confirm that others might not be able to
[11:12] <sits> the problem is it would only be a matter of time before people started gaming the system
[11:12] <bradb> bug 3382 might interest you
[11:12] <Ubugtu> Malone bug 3382 in malone "Should be able to attach hardware database id to bugs" [Normal,Confirmed]  http://launchpad.net/bugs/3382
[11:12] <sits> ahem
[11:12] <sits> take a look at who filed that one...
[11:13] <bradb> ah
[11:13] <sits> at least I'm consistent...
[11:13] <bradb> indeed
[11:13] <sits> another little problem that keeps coming up are attachments
[11:14] <sits> it's absolute murder looking at bugs where people have posted the entirety of xorg.conf and dmesg into the body of the bug itself
[11:15] <sits> and yet asking people to use Add Attachment is itself not a great solution
[11:15] <sits> the other day someone outsmarted me by uploading the requested output as an openoffice.org writer file
[11:15] <sits> I can see just how it happened
[11:15] <sits> but it's hard to remember to say:
[11:16] <sits> "Please can you attach (using the Add Attachment link in the malone website) the output of the
[11:16] <sits> /etc/X11/xorg.conf
[11:16] <sits> file as a text file"
[11:16] <bradb> bug 32282 perhaps?
[11:16] <Ubugtu> Malone bug 32282 in malone "Try to reduce of the amount of LONG comments" [Wishlist,Confirmed]  http://launchpad.net/bugs/32282
[11:17] <sits> bradb: wow you ARE good
[11:17] <bradb> :)
[11:17] <sits> There needs to be a bradb bot
[11:17] <bradb> heh
[11:17] <sits> ok here's another one
[11:18] <sits> rather thornier
[11:18] <sits> what's to be done about bugs on binary products?
[11:18] <sits> I see that there are two sensible paths
[11:18] <sits> the SUSE let's get the binary producer on board to look at bugs filed in our bugzilla route
[11:19] <bradb> wait, what's a binary product?
[11:19] <sits> or the RH hardass you're binary only problem need to be taken directly to the producer of the binary
[11:19] <sits> bradb: where the source is not available
[11:19] <sits> e.g. acroread, nvidia binary driver etc.
[11:20] <sits> s/you're/your
[11:20] <bradb> sits: how does that work. is it like a binary package with no source package?
[11:20] <sits> bradb: precisely
[11:21] <bradb> hm
[11:21] <sits> if you go to the RH bugzilla with an nvidia binary driver problem they will point you at nvidia and the nvnews forum and promptly close your bug
[11:21] <sits> (this of course causes ill feeling and massive arguments but the bugs are always closed)
[11:21] <sits> in fact
[11:22] <sits> if your kernel is tainted at all and you have a kernel problem that can get the bug closed too
[11:22] <sits> it's brutal but it keeps the bug tracker clean and full of theoretically solvable bugs
[11:23] <sits> in fact there's another thing that can cause a bug to get closed quickly
[11:23] <sits> you get asked to take it upstream (e.g. a xorg problem) and then it is closed in the RH bugzilla
[11:24] <bradb> I'd have to discuss with the Ubuntu team what their support policy is for binary-only packages to learn more about how we can model it in Malone.
[11:24] <sits> it's quite aggressive but it does stop the bug count getting out of control because a lot of bugs are resolved the same blunt ways
[11:25] <sits> bradb: I'm just chucking stuff around
[11:25] <bradb> as a user, I know I'd hate to be told to go elsewhere.
[11:25] <sits> the SUSE way is they seem to have good ties with nvidia
[11:26] <sits> if I want to know if a new binary driver release is imminent or try to get hold of an NVIDIA engineer you can try filing there as they seem able to "call" NVIDIA people over to look at stuff
[11:26] <sits> compared to RH they are friendly to binary only vendors
[11:26] <sits> and appear to have the working relationships
[11:27] <sits> SUSE engineers sometimes look at problems involving binary drivers and try and resolve them too
[11:27] <sits> and they seem to be among the few people who will work on the nv OSS driver
[11:28] <bradb> I don't think Malone can do much about support team policy, only about being able to capture binary-only bugs at all.
[11:28] <sits> the problem is these binary bugs stack up
[11:28] <sits> and they can be hard to reduce into each other
[11:29] <sits> e.g. do you blame all weird lockups containing nvidia binary drivers on nvidia binary drivers?
[11:29] <sits> hey that's reminded me of something else
[11:30] <sits> (besides the fact that I'm recently unemployed : )
[11:30] <sits> the many bugzilla's have grown needinfo which has the useful feature of unsetting itself once a bug is replied to
[11:31] <sits> the RH bugzilla goes one further and also has needinfo_reporter which avoids the unsetting until the original reporter replies
[11:31] <sits> RH use this to resolve what seem to be called "Hit and Run" bug reports
[11:32] <sits> you set the flag and then after (say) 30 days of no response you assume the reporter isn't coming back
[11:32] <bradb> there's been some similar discussion about doing that in malone, bug 5786
[11:32] <Ubugtu> Malone bug 5786 in malone "NeedsInfo should be moved into a separate bug or bugtask flag" [Normal,Confirmed]  http://launchpad.net/bugs/5786
[11:32] <bradb> and bug 35344
[11:32] <Ubugtu> Malone bug 35344 in malone "Automatic bug expirations" [Normal,Unconfirmed]  http://launchpad.net/bugs/35344
[11:33] <sits> ah excellent
[11:34] <sits> Mandriva used to engage in mass closures once per release cycle
[11:35] <sits> it's painful as a user but again it helps keep bug counts down
[11:35] <sits> oh and while I remember - it's hard to know whether I'm doing the right thing
[11:35] <sits> at the moment I am setting bugs to confirm when I too can reproduce the problem
[11:36] <sits> where I think a bug is a duplicate of another bug I add a comment saying I think that it is a dup of Bug #XYZ
[11:36] <sits> sometimes I just add a long comment if you touch upon an area I happen to have explorered
[11:37] <sits> quite often I just ask for dmesg/lspci/xorg.conf output to try and move the bug out of the Ubuntu product
[11:37] <sits> am I doing the right thing or am I making a nuisance out of myself?
[11:38] <sits> (also right now there's no easy way to find bugs you've commented on so I can follow up and see whether the things I thought were dups were later marked as dups etc. and self score)
[11:38] <sits> I use my browser's history to try and retrace my steps but it's not easy
[11:39] <bradb> well, with the perms as they currently are, Malone is suggesting that anybody who can confirm a bug should. if developers using Malone start complaining that this is too permissive, then we'll have to rethink the permissions.
[11:39] <sits> although whichever smart alec set the default number of Ubuntu bugs to be displayed to 75 magically got me looking at more bugs per day
[11:39] <bradb> the same could be said of marking a dup
[11:39] <sits> hmm
[11:40] <sits> (oh and thanks to whoever unshrank the bug list font size - you saved my eyesight!)
[11:40] <bradb> drive-by commenting when you think you have something to contribute seems ok to me, and will be made a little smoother once i fix bug 977 (which i started fixing today, actually)
[11:40] <Ubugtu> Malone bug 977 in malone "Commenting on bug should optionally subscribe you" [Major,In progress]  http://launchpad.net/bugs/977
[11:41] <sits> ah well that's close
[11:41] <sits> but not quite the same
[11:41] <sits> er let's see
[11:42] <sits> ok I can't work out how you make Ubugtu go. Which command do I need?
[11:43] <bradb> bug NNNN
[11:43] <sits> oh I see
[11:45] <sits> hmm I don't appear to have reported it
[11:45] <bradb> sits: do you think there's a need to distinguish bugs you've commented on vs. bugs you're subscribed to?
[11:45] <sits> I guess I should file a bug saying "not easy to find bugs you've added a comment on"
[11:46] <sits> yeah, I only want to subscribe to interesting bugs
[11:46] <sits> and I want the subscription list to me comparatively small
[11:46] <sits> with RH's over the top bugzilla I can do a query which says bring me up any bug I've commented in that has changed in the past 30 days
[11:47] <sits> so I can dip in out extremely casually in bug tracking
[11:47] <sits> that is probably a very weird use case though
[11:47] <bradb> bug 36060 is bringing us in that direction too
[11:48] <Ubugtu> Malone bug 36060 in malone "Bug needs a date last updated column" [Critical,Confirmed]  http://launchpad.net/bugs/36060
[11:48] <bradb> it's another current priority for me
[11:52] <sits> dup identification is another massive area
[11:53] <sits> once upon a time Mandriva tried searching their bug db for words you typed into your bug and warning you which bugs looked similar
[11:53] <sits> it brought back an awful lot of false positives though
[11:55] <sits> however
[11:55] <sits> searching the dup list can be very interesting
[11:56] <sits> providing a dup is left in it's originally location it can often serve as a pointer to popular issues
[11:56] <sits> because people "misthink" in similar ways
[11:58] <bradb> bug 30307 has an interesting idea for searching dupes
[11:58] <Ubugtu> Malone bug 30307 in malone "omit_dupes and searching" [Minor,Confirmed]  http://launchpad.net/bugs/30307
[11:59] <bradb> on the reporting side, bug 37425 has an idea for how to deal with common misthinks
[11:59] <Ubugtu> Malone bug 37425 in malone "Prevent duplicates by suggesting products/packages holding targets of many other duplicates" [Normal,Unconfirmed]  http://launchpad.net/bugs/37425
[12:04] <bradb> sits: I'm planning to head off now, but by all means, feel free to peruse Malone, report bugs, comment on issues that you have a particular interest in seeing fixed sooner rather than later, etc. Feedback is always welcome.