[02:00] <wgrant> sinzui: I somehow feel that the Launchpad importance categorisation system doesn't work well, after seeing all of your Answers triage.
[02:01] <sinzui> wgrant: it does not
[02:01] <sinzui> critical means stop work and fix it now
[02:01] <sinzui> high means we commit to fix it in 3 cycles and schedule and assignit
[02:02] <sinzui> low is anything what we cannot commit people to
[02:02] <wgrant> Sometimes I really wish priority and severity were still separate fields.
[02:02] <sinzui> We are still discussing dropping the other importances
[02:02] <wgrant> Wishlist needs to die, and you seem to feel the same about Medium.
[02:03] <wgrant> But I like Medium.
[02:03] <sinzui> wgrant: what does medium mean to you
[02:03] <wgrant> sinzui: I'm not sure, but other projects use milestones to track what you seem to use importance for.
[02:03] <wgrant> Few other projects define High/Low based on whether they can find resources.
[02:04] <sinzui> BjornT:  likes medium, but it is personal. we medium is not more likely to be fixed than a low. It is a logistical problem really
[02:04] <wgrant> After seeing what has been done to Answers, I am sure that Launchpad has it wrong.
[02:04] <sinzui> https://dev.launchpad.net/BugTriage
[02:05] <wgrant> What happens when Answers gets some love? The bugs are no longer ordered.
[02:05] <sinzui> wgrant: I am being honest about what will be fixed
[02:05] <wgrant> I know.
[02:06] <sinzui> wgrant: We look at the business objects and User demand to create stories that define the themes to makr bugs as High
[02:06] <sinzui> Answers and bugs still get critical issues, and they are fixed immediately.
[02:06] <wgrant> s/bugs/blueprints/?
[02:07] <sinzui> correct, blueprints.
[02:07] <wgrant> You seem to be changing the old definition of importance (a combination of priority and severity) to mean only priority.
[02:07] <wgrant> And that priority is global across all of launchpad-project.
[02:08] <sinzui> I think I want them separate again too
[02:08] <wgrant> Which makes priorites apart from Critical impossible for Answers and Blueprints, except for changes necessitated by other Launchpad changes.
[02:08] <wgrant> s/priorites/importance/
[02:08] <sinzui> wgrant: but that is true
[02:09] <wgrant> So if Answers, by some act of god, gets somebody working on it... how do they know what to do?
[02:09] <sinzui> I can only work on these application after hours
[02:10] <wgrant> Right.
[02:10] <sinzui> wgrant:  as I said business objectives and user demand. representatives from each group (there is about 7 groups) get 3 issues that I will put into the prioritisation list
[02:10] <sinzui> if close an issue, from a list another can be added
[02:10] <wgrant> sinzui: Interesting...
[02:10] <sinzui> stakeholders can always change their list, at any time
[02:11] <sinzui> We will be reorganising stakeholders at UDS
[02:11] <wgrant> I don't think the third paragraph of 'The Problem with "Medium"' is a bad idea.
[02:12] <sinzui> https://dev.launchpad.net/VersionThreeDotO/Registry needs better input...the stake holds need to be more repesenative
[02:13] <sinzui> wgrant:I think tags are much better at discovering the themse of bugs to understand what needs to be done, and that allows us to update importance
[02:15] <sinzui> wgrant: you can see from my completed bugs, 2/3 are low, but I fixed them in an opportunist fashion. I had a time box to complete a high bug, and I closed some easy low ones since I had time left
[02:15] <wgrant> sinzui: Perhaps. But there are some bugs that are almost objectively of higher importance than others (for example, I saw one about Answers misattributing bug comments and status change messages - that has to be higher importance than a typo)
[02:16] <wgrant> But under the Launchpad triage guidelines, they are both Low. Just because there are no engineers on Answers.
[02:16] <wgrant> There is no way to distinguish them.
[02:16] <sinzui> wgrant: I agree, there are many degrees. That is why the person who does triage must reevaluate everything.
[02:17] <wgrant> What happens when community developers appear on the scene in Launchpad?
[02:17] <sinzui> wgrant: This model reflects what happens,
[02:18] <sinzui> wgrant: I would remove critical. just use three states, high, medium, low. Or do now, schedule for near future, fix opportunisticaly
[02:19] <sinzui> If I could fix the blueprint statues, they would be essential, expected, and optional
[02:19] <wgrant> sinzui: 'schedule for the near future' is much better handled by targetting/milestoning to a series.
[02:20] <sinzui> wgrant: We have  had lots of bugs assigned to milestones and persons that never get fixed. Only the high items really get fixed
[02:20] <sinzui> medium and low always slip
[02:21] <sinzui> the problem is...if a high bug is not fixed in a year, it clearly was not high, Other things were fixed instead
[02:21] <wgrant> Right.
[02:22]  * Nafallo waits for the state "OMGTHEWORLDENDS"
[02:23] <wgrant> The conflation of severity and priority years ago really seems to have been a bad idea, in retrospect.
[02:23] <wgrant> As was the introduction of Wishlist as an importance.
[02:23] <sinzui> We do need to fix importance, priority, and status in bugs and blueprints. We avoid blueprints. We Will have people on Answers and Blueprints in a few months, and then interment. every quarter.
[02:23] <wgrant> Oh, really?
[02:23] <wgrant> I imagined they were orphaned indefinitely.
[02:24] <sinzui> wgrant: We need both those apps to do our job, and they do not work for us
[02:24] <wgrant> sinzui: I don't think Blueprints and Bugs should be separate apps.
[02:24]  * sinzui high five's wgrant
[02:25] <wgrant> Answers needs to be separate, and needs fixing, yes. But Blueprint?
[02:26] <wgrant> Having features/bugs split in listings, for example, is a good thing, but they are so similar that IMO it should just be a flag on the object...
[02:26] <wgrant> And I don't understand why it was ever done the other way.
[02:26] <wgrant> Nor why Wishlist exists.
[02:27] <wgrant> Change Wishlist into a flag, perhaps add a couple of extra fields to bug tasks, and kill off Blueprint forever. Maybe.
[02:31] <sinzui> wgrant: A lot of us agree with you.
[02:32] <sinzui> The problem now is that now that we have it, how do we fix it so that is a tool to plan a release instead of a record of what someone wants?
[02:36] <wgrant> sinzui: It sounds to me like you need to have a big get-together of lots of stakeholders... rather convenient that there's on this week and next.
[02:36] <sinzui> indeed
[02:37] <batoms> ive been trying to dput to my ppa and the upload succeeds but i don't get a confirmation email
[02:38] <sinzui> wgrant: I'm sure the stake holders will change when we open source. I also hope that priorities will change when more people can help fix the issues that concern them most
[02:38] <batoms> and the package doesn't show on my ppa page
[02:38] <batoms> anyone have any ideas?
[02:38]  * sinzui thinks
[02:40] <sinzui> batoms: are you receiving other email from Launchpad?
[02:40] <batoms> sinzui: what other types of emails? i'm not getting anything related to the upload of the package
[02:41] <sinzui> bug emails? team emails?
[02:41] <wgrant> batoms: OK, there are a couple of things to check. Have you waited more than five minutes? Is the _source.changes signed with your key? Is that key registered with your account on Launchpad?
[02:44] <batoms> let me double check the key
[02:47] <wgrant> batoms: Also check that Changed-By and Maintainer in the .changes have non-obfuscated email addresses.
[02:47] <wgrant> That has caused silent failures in the past, but I'm not sure if that still happens.
[02:49] <batoms> i think it might be my gpg key, mine has changed recently
[02:50] <batoms> i'll check all those things, thanks
[03:23] <batoms> should the incoming line in .dput.cf be ~whatever/ubuntu or ~whatever/ppa/ubuntu if uploading to your group PPA
[03:24] <Sarvatt> ~whatever/ppa/ubuntu
[03:25] <batoms> after uploading my new gpg key i can now get the confirmation email...unfortunately its to confirm my rejection
[03:42] <wgrant> batoms: Either of those should work, but the latter is the new, preferred one.
[05:51] <Peng_> Is it just me, or does LP take longer to mirror new branches than it used to?
[05:53] <wgrant> Peng_: You mean scan, so they show in the web UI?
[05:54] <wgrant> Or mirroring remote branches?
[05:55] <Peng_> wgrant: I mean the actual mirroring.
[05:56] <jml> Peng_: it's possible -- we don't have any graphs tracking that.
[05:56] <Peng_> :D
[05:58] <jml> Peng_: do you have any data supporting your hypothesis?
[06:17] <Peng_> jml: No, I don't.
[06:18] <Peng_> I've been noticing this for at least a couple weeks, too. I'm a useful user, eh? :P
[06:18] <jml> Peng_: ahh, even anecdotes are better than nothing.
[06:18] <jml> Peng_: I can have a poke around later on and see if there's a cheapish way of gathering data on how long mirrors take.
[06:19] <jml> (note the unspecified time frame)
[06:20] <Peng_> This may have been since the last rollout, or longer. :\
[06:20] <jml> what leads you to make the suggestion
[06:20] <jml> I'm wondering if it's just the big yellow notice on the web page
[06:21] <Peng_> jml: Is the "Last mirrored" statistic on branch pages based on the scanner or the puller?
[06:22] <jml> Peng_: puller.
[06:22] <Peng_> jml: It took 12 minutes to mirror a branch I just added, then. I have no proof, but it felt like it only took a few minutes in the past.
[06:23] <jml> ok.
[06:23] <jml> that's interesting
[06:25] <jml> Peng_: so, I can't come up with any convincing explanations for it getting slower.
[06:25] <jml> Peng_: *but* I do know that we're making the puller more responsive in the next cycle or so.
[06:26] <Peng_> OK, cool. Thanks. :)
[06:27] <Peng_> 12 minutes obviously isn't a huge issue, but felt different to me, so I wanted to bring it up.
[06:27] <jml> yeah, thanks for doing os.
[06:27] <jml> I really want to write a Bazaar plugin that requests a mirror using the Launchpad API also,
[06:27] <jml> but - sadly - I must write this talk first.
[06:30] <Peng_> How would the plugin work? Would it run automatically after pushing or something? How would it know if/where the branch was mirrored?
[06:33] <jml> Peng_: well, at the simplest level, it could just be 'bzr request-mirror <branch_url>'
[06:33] <jml> Peng_: I don't know if Bazaar has a post-push hook or equivalent.
[06:34] <jml> Peng_: It could also try divining the Launchpad branch from the public branch location.
[06:34] <jml> because for many mirrored branches it could make sense for the push location to be the server and the public location to be Launchpda.
[06:42] <Peng_> jml: I'd be happy with just "bzr request-mirror <branch-url>".
[06:42] <jml> Peng_: yeah, me too, I think.
[06:42] <jml> Peng_: also, I need to figure out a way of writing a launchpadlib application that tells you when your branch has been mirrored.
[06:43] <Peng_> jml: In my case, the public location is set to my server, not LP. If it was possible to pass that URL to LP and get back the LP URL for that branch, that'd be totally neat, though. :D
[06:43] <jml> Peng_: that's not already provided?
[06:43] <Peng_> jml: I have no idea.
[06:43]  * Peng_ knows nothing of the API.
[06:43] <jml> hmm.
[06:44] <jml> well, there's definitely a thing we already have in the code, and something that we should provide if we don't already
[07:10] <lifeless> jml: bzr help hooks | grep -> post_push, and also there is post_branch_tip_change
[07:10] <jml> lifeless: that's good to know.
[07:11] <jml> help hooks would have been my first port of call, too.
[07:37] <Peng_> This time, it took 14 minutes. :D
[10:17] <Peng_> Did you just take away the ability to move branches to a different project the day I accidentally put some branches in the wrong project? :(
[10:19]  * Peng_ temporarily turns off the edge redirect to fix them. :)
[10:50] <tzepu_> hello, i am having a problem in signing Ubuntu code of conduct with the error 'no public key' when hitting continue
[10:51] <tzepu_> i downloaded 2 times the document and assured that i copy all its content and still get that error, any advice?
[11:11] <Peng_> FWIW, I've registered several more mirrored branches, and they were all mirrored in ~12-14 minutes too.
[11:48] <stefanlsd> I have a ubuntu package in bzr which i would like two devs (maybe more) to work on.  Instead of everyone having their own branch that we need to merge, is creating a team the only way to achieve a 'shared' branch?
[11:51] <wgrant> stefanlsd: Yes.
[11:51] <stefanlsd> wgrant: thanks :)
[12:14] <happyaron> Hi, I uploaded a package to my ppa with errors, so it returns build failures, but how can I re-upload the exact file that I've fixed the problem?
[12:18] <happyaron> anyone know how to solve?
[12:18] <Nafallo> bump the revision?
[12:20] <happyaron> Nafallo: you mean that I should change a version?
[12:21] <happyaron> anyway, it always tells me that the newly uploaded .diff.gz already exists in PPA
[12:31] <jpds> happyaron: Yes, change the version number in debian/changelog.
[12:31] <happyaron> jpds: thank you
[13:13] <Ampelbein> Hi there. Could it be that the official hppa-builders are a little... dead? For example https://edge.launchpad.net/builders/kohnen builds the same package for 7 days. I can't imagine that is correct ;-)
[15:20] <BUGabundo> congrats on the new edge bug page!
[15:20] <BUGabundo> looks so smooth
[16:01] <Kangarooo> how can I make a pool ?
[16:02] <Kangarooo> ui poll in launchpad
[16:02] <BUGabundo> Kangarooo: only in a project you can do a poll
[16:05] <Kangarooo> ok and then? or only team manager can make them?
[16:05] <BUGabundo> not sure
[16:05] <Kangarooo> here https://launchpad.net/~xubuntu-users/+polls was one poll but I don't see button to make new
[16:13] <charlie-tca> I think it is administrators only
[16:20] <BUGabundo> charlie-tca: aren't you on the admin team for xubuntu ?
[16:20] <BUGabundo> welcome sabdfl
[16:20] <charlie-tca> I don't think so
[16:31] <MisterBax> lo
[16:31] <MisterBax> oupse sorry
[16:33] <BUGabundo> hehe MisterBax
[17:25] <ranok> Hello, I'm having troubles uploading a largeish package to my PPA, it gets to 1k less than the total size, then hangs
[19:12] <mithro_> Hey guys, my ppa has ran out of space again :(
[19:16] <mithro_> although I'm not sure why this time
[19:16] <mithro_> are old binary packages auto-purged?
[19:18] <mithro_> https://answers.launchpad.net/launchpad/+question/69460
[19:23] <mithro_> anyone alive today? Or should I head to bed and check back tommorrow?
[19:33] <johan_inkscape> hi all
[19:33] <johan_inkscape> how do i sort the bugs in launchpad by the time of their last changes?
[19:39] <intellectronica> johan_inkscape: go to the advanced search form and select "by: most recently changed" from the dropbox at the top
[19:40] <johan_inkscape> ah wow, sorry for the dumb question
[19:46] <johan_inkscape> is it possible to add this "last changed" date/time to the columns in the bug listing?
[19:53] <bryce> hi johan_inkscape
[19:53] <johan_inkscape> hey bryce
[19:53] <bryce> johan_inkscape: not in launchpad directly afaik
[19:53] <johan_inkscape> trying to figure out the bug listing in launchpad
[19:53] <bryce> johan_inkscape: what exactly do you need?
[19:54] <johan_inkscape> it's just nice to see in the listing when a bug was touched for the last time
[19:54] <johan_inkscape> another thing:
[19:54] <johan_inkscape> the list of tags has shortened *a lot* for inkscape
[19:55] <johan_inkscape> (i can't find the "crash" tag that used to be listed on the right for example)
[19:55] <bryce> I've found sorting by last changed is usually sufficient.  Other than that it is possible to query via launchpadlib if for instance you want only bugs newer than N days or some such
[19:56] <bryce> johan_inkscape: they implemented an official/unofficial thing for tags
[19:56] <bryce> so possibly "crash" just needs added for inkscape's official list
[19:56] <johan_inkscape> ok
[19:58] <bryce> here I can add it
[19:58] <bryce> any other tags that should go into the official list?
[19:59] <johan_inkscape> i don't know what tags we have
[19:59] <johan_inkscape> live path effect, or lpe ?
[19:59] <johan_inkscape> thanks bryce
[19:59] <bryce> livepatheffects - ok
[19:59]  * hyperair wonders if bryce has a /ignore on in #ubuntu-x.
[20:00] <bryce> hyperair: just a minute, let me finish helping johna first
[20:00] <hyperair> no hurry ;)
[20:01] <bryce> johan_inkscape: ok I added a couple dozen that look popular, including those two
[20:01] <johan_inkscape> yeah i see
[20:01] <johan_inkscape> thanks
[20:02] <bryce> johan_inkscape: let me or one of the other inkscape admins know if you have others to propose adding
[20:02] <johan_inkscape> ok
[20:09] <lizardmenke> Hi I'm beta-testing on ubuntuone and now I want to change my launchpad password. Will changeing my LP password affect my access in my ubuntuone account?
[20:12] <lizardmenke> Or should I rather be asking this question in ubuntuone channel?
[20:32] <beuno> lizardmenke, it won't
[20:32] <lizardmenke> Ok thanks I'll go ahead and change it then
[23:29] <MTecknology> Is it possible to do bzr push to a non existing branch?
[23:30] <MTecknology> Like this: bzr push lp:~mtecknology/temp
[23:42] <wgrant> MTecknology: Yes; that's how you're meant to create branches. But that's not a valid branch path!
[23:45] <MTecknology> wgrant: there we go - thanks :)
[23:45] <MTecknology> that's pretty cool :)
[23:47] <wgrant> It is.