[00:22] <wallyworld_> huwshimi: do you have thoughts on how to display links that are not valid? hide or render as disabled?
[00:23] <huwshimi> wallyworld_: Oh is this from the same as that email I got? Sorry I've been away sick the last few days
[00:24] <wallyworld_> huwshimi: np. when you have some spare cycles, have a think and let me know
[00:25] <huwshimi> wallyworld_: Thanks, I should get to it today
[00:26] <wallyworld_> huwshimi: ok. you know the context etc i assume then? ie the bug task page and the "Also Affects" links. but i think we need a consistent policy for the product as a whole
[00:27] <huwshimi> wallyworld_: Yeah, I think Francis's email has some info
[00:28] <wallyworld_> cool
[00:38] <poolie> wgrant, i wonder what you would think of https://code.launchpad.net/~mbp/launchpad/show-timeline/+merge/80166
[00:39] <poolie> huwshimi, :-(
[00:39] <huwshimi> poolie: Sorry :)
[00:40] <poolie> is this actually less readable?
[00:41] <poolie> some text is not wrapped at all and people cope
[00:42] <huwshimi> poolie: Yes, and I don't want to make a regression and add to existing readability issues
[00:46] <poolie> i anticipate markdown getting bikeshedded to death :/
[00:46] <huwshimi> poolie: Why is that?
[00:50] <poolie> oh, just previous similar changes, but i should be optimistic
[00:50] <poolie> perhaps it can be done
[00:53] <lifeless> poolie: in regards to the user commenting on a bug, or some other context?
[00:53] <poolie> lifeless, what do you mean?
[00:54] <lifeless> the markdown comment
[00:54] <poolie> i think it would eventually go everywhere
[00:54] <lifeless> the only reference to markdown I've read recently was a random popping into an old bug saying 'use markdown'
[00:54] <poolie> huwshimi, i do respect your right to decide about it
[00:54] <poolie> it is much better that someone is making the decisions
[00:55] <poolie> lifeless, in the context of  https://code.launchpad.net/~mbp/launchpad/bug-width/+merge/80161
[00:55] <poolie> i guess i'm just disappointed because for me, it was a big improvement and pretty easy to do
[00:55] <poolie> i will try to be an adult
[00:56] <wgrant> s/be an adult/use greasemonkey/?
[00:56] <poolie> i suppose i feel there is also a general bias that "whatever crap currently exists" >> "something new but not perfect"
[00:56] <poolie> but, if 45em really is the ideal width for text on a bug conversation, or close enough to ideal, that's ok
[00:56] <lifeless> ah
[00:57] <poolie> wgrant, yeah, or in fact probably a local stylesheet is enough
[00:57] <lifeless> we don't have a good regression test suite around appearance
[00:57] <poolie> but that too is disappointing
[00:57] <lifeless> and huw is currently deep in an overhaul of appearance - the rebranding effort
[00:57] <poolie> lifeless, i know
[00:58] <lifeless> so its kindof hard right now to assess whether something is a win or not, because its so complex :(
[00:58] <poolie> i think having humans assess regressions against a style guide would be nice
[00:58] <poolie> perhaps the canonical style guide does cover this
[00:58] <lifeless> I'm hoping one of the outcomes of the rebranding will be simpler presentation permitting easier understanding of changes like your proposed one
[00:59] <lifeless> that said, I too am a little confused - I don't understand where we would lose usability with your change (but see under hard to asess because complex)
[00:59] <poolie> so, very wide text is hard to read
[01:00] <poolie> for example, mp comments don't wrap at all before the screen width, so they are slightly hard to read on wide monitors
[01:00] <poolie> (unless, as fairly often happens, they are wrapped in the incoming email)
[01:00] <poolie> i agree this is a problem, i just don't think using 80em is enough for the problem to bite seriously
[01:01] <poolie> or at least it is a reasonable tradeoff
[01:03] <poolie> lifeless, thanks for the review. what is ++profile++show
[01:03] <poolie> ?
[01:06] <lifeless> add this feature rule locally
[01:07] <lifeless> profiling.enabled default 0 on
[01:07] <lifeless> then visit /++profile++/
[01:07] <lifeless> this generates an oops, then renders it in an overlay profile
[01:08] <lifeless> there are two reasons we might not want to do that here: we don't want to send an oops on every developer request (but you can call create() and not publish() to achieve that)
[01:08] <lifeless> and secondly there may be enough overhead to want to avoid it for regular developer requests (but thats unknown)
[01:08] <lifeless> if you consolidated these code paths, it could be a pretty neat experience
[01:12] <poolie> huh
[01:13] <lifeless> the oops adds info like the pageid, which tells us the api or view invoked, host it ran on, execution time, and as we add things like thread rusage, that too
[01:15] <poolie> yes that would be neat
[01:15] <poolie> for this i wanted to make it something that would always be cheap enoguh to have available, at least to developers
[01:16] <lifeless> I would be surprised if generating and not sending an oops were more than a few 10's of ms
[01:16] <poolie> separately, i looked at https://bugs.launchpad.net/launchpad/+bug/878140 too but i'm stumped
[01:16] <_mup_> Bug #878140: process-mail.py failed to resolve dns. Raised NXDOMAIN <dkim> <oops> <Launchpad itself:Triaged by mbp> < https://launchpad.net/bugs/878140 >
[01:35] <poolie> StevenK, thanks for working on updating twisted
[02:53] <lifeless> StevenK: wgrant: has sinzui set you loose on criticals or something ?
[02:55] <wgrant> StevenK was for a while.
[03:06] <StevenK> lifeless: I will tend to look at criticals when I'm booked -- sinzui has said that is okay.
[03:06] <StevenK> s/booked/blocked/
[03:06] <StevenK> And that twisted critical has been annoying me for a while.
[03:07] <wgrant> We're nearly unblocked, finally.
[03:08] <StevenK> I was pondering refactoring the switch team visibility to check for a PPA and private bug subscriptions
[03:09] <StevenK> s/visibility/subscription policy/
[03:09] <wgrant> Visibility, or membership policy?
[03:09] <wgrant> Right.
[03:09]  * StevenK de-prams his toys
[03:09] <wgrant> There's several cards about extending the restrictions.
[03:09] <wgrant> We need the restriction you are pondering, but it needs to be somewhat extensible.
[03:10] <StevenK> Right
[03:10] <StevenK> wgrant: Jump on mumble then?
[03:11] <wgrant> Uhoh.
[03:11] <StevenK> I can't have a few minute pre-impl? :-)
[03:11] <wgrant> Critical bug balance over the last week is -16.
[03:11] <wgrant> I need to file bugs :(
[03:14] <lifeless> huh
[03:14] <lifeless> I thought we showed a padlock for links to private things
[03:15] <lifeless> have a look at bugs.l.n/python-oops-tools
[03:15] <wgrant> lifeless: That table is special.
[03:15] <wgrant> https://bugs.launchpad.net/python-oops-tools/+bugs
[03:16] <lifeless> aieeee
[03:17] <wgrant> Not quite sure why +bugs isn't the Bugs index now.
[03:18] <wgrant> +bugs-index is pretty much a crippled, hideously useless version of +bugs.
[03:18] <lifeless> by heat
[03:18] <wgrant> Like Archive:+index vs Archive:+packages
[03:18] <wgrant> Except that we have a vision for Archive:+index.
[03:24] <elmo> wow
[03:25] <wgrant> elmo: What have I done now?
[03:26] <elmo> https://chinstrap.canonical.com/~james/nx/wtf.png
[03:26] <wgrant> Indeed.
[03:26] <wgrant> If you look down the bottom you can see the real error.
[03:27] <elmo> yeah, I saw it
[03:27] <wgrant> This wonderful error handling has been in place since early 2009 :)
[03:28] <elmo> hmm, I don't think so
[03:28] <elmo> or maybe I've been using refcontrol longer than I thought
[03:28] <elmo> in any event, when I first started using refcontrol, it failed in less spectacular ways
[03:28] <wgrant> It's a bit less ugly for non-AJAX operations.
[03:28] <elmo> is there a bug about it and/or should I file one?
[03:28] <elmo> ah, that could be it
[03:28] <wgrant> It still uses ALLCAPS for no reason at all.
[03:29] <wgrant> But at least doesn't spew JS at you.
[03:29] <wgrant> I think there's a bug, but I can't find it.
[03:29] <wgrant> Ah
[03:29] <wgrant> Bug #521447
[03:30] <_mup_> Bug #521447: ajax errors show 'following errors occured' or a big dump of the html source for the oops page <error-handling> <errors> <javascript> <lp-bugs> <ui> <Launchpad itself:Triaged> <LAZR Javascript Library:Triaged> < https://launchpad.net/bugs/521447 >
[03:30] <poolie> huwshimi, lifeless, the text width thing would be a case where it would be interesting to have google labs style per-user feature flags
[03:30] <wgrant> Also
[03:30] <wgrant> bug #408491
[03:30] <_mup_> Bug #408491: Javascript actions error handling needs work <javascript> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/408491 >
[03:30] <poolie> to say "you can opt in to wide text", or markdown, or whatever
[03:30] <poolie> and see what happens
[03:31] <poolie> elmo, Note the consistent user interface and error reportage. Launchpad is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
[03:31] <elmo> poolie: haha
[03:32] <nigelb> Hrm, no jtv yet.
[03:33] <elmo> (oh, sorry - I didn't mean to post that chinstrap link in here - non-canonical folks can infer the contents from the bug wgrant linked to)
[03:33] <wgrant> Hah, I assumed this was -ops.
[03:34] <wgrant> You don't often venture out here :)
[03:34] <nigelb> elmo: I'm guessing you had a whole bunch of red text as the outcome of a failed ajax operation
[03:34] <nigelb> wgrant: hehe
[03:42] <lifeless> poolie: that was a little mean :(
[03:45] <lifeless> still winning -
[03:45] <lifeless>     2029  OOPS-2122AX39   Product:+activereviews
[03:45] <wgrant> Product:+download is a pretty easy one, hopefully.
[03:46] <wgrant> Just lots of LFADC queries.
[04:36] <huwshimi> wallyworld: I've just replied to that email about hiding/disabling. Let me know if that doesn't help
[04:36] <wallyworld> huwshimi: thanks. will look
[04:36] <wallyworld> huwshimi: i also want to ask you about something else when you have a moment
[04:37] <huwshimi> wallyworld: sure, anytime
[04:37] <wallyworld> huwshimi: as an aside, there's a weird css glitch with the edit icons used for the yui activator - they are a few pixels higher than the text they go next to
[04:37]  * StevenK melts from the heat.
[04:38] <wallyworld> which leads me to this screenshot
[04:38] <wallyworld> http://people.canonical.com/~ianb/bugtask-remove-icons.png
[04:38] <wallyworld> huwshimi: i want to provide ui to delete bug tasks, so the screenshot puts the remove icons next to those tasks that are allowed to be deleted
[04:39] <wallyworld> but it looks crap due to the css issue i just highlighted
[04:39]  * StevenK kicks Unity.
[04:39] <wallyworld> note that other edit icons in the same row are aligned
[04:39] <wallyworld> i've had a quick look at the css but nothing jumps out at me as being the obvious cause
[04:40] <wallyworld> huwshimi: so, i need input on the placement if the remove icons plus whether we want to fix the edit icon alignment
[04:40] <huwshimi> wallyworld: the remove icons have the correct alignment. We need to fix the edit icons
[04:40] <huwshimi> wallyworld: Is there a way for me to run that code locally?
[04:41] <wgrant> Even better if you can remove that couple of em of padding between the expander and icon.
[04:41] <wallyworld> huwshimi: to do that screenshot, i just run lp.dev and hacked the html with "<a class='sprite remove'></a>
[04:41] <wgrant> I tried, but lazr-js is ew.
[04:42] <wallyworld> we no longer use lazr-js :-)
[04:42] <huwshimi> wallyworld: Ah great
[04:42] <wallyworld> but we use its code
[04:42] <wgrant> We use lazr-js, just it happens to have been merged into our tree.
[04:42] <wallyworld> huwshimi: so use firebug i assume
[04:42] <wallyworld> s/so/you
[04:42] <huwshimi> wallyworld: yeah that's fine
[04:42] <wallyworld> wgrant: i know, i was trying to be 'funny'
[04:43]  * wallyworld needs coffee
[04:43] <huwshimi> wallyworld: Oh was that a question?
[04:43] <wallyworld> huwshimi: what was?
[04:44] <huwshimi> wallyworld: Did your correction mean you were asking if used firebug?
[04:44] <wallyworld> huwshimi: yeah, just making sure you were able to hack in the html like i did
[04:45] <huwshimi> wallyworld: Ah yes that's fine
[04:45] <huwshimi> wallyworld: Just waiting for my launchpad to update
[04:45] <wallyworld> cool. i thought it would be, just making sure :-)
[04:45] <wallyworld> np
[04:46] <wallyworld> i'm waiting for your email to arrive
[04:46] <wallyworld> so i'll go grab a caffinated beverage
[04:46] <huwshimi> wallyworld: Oh strange
[04:47] <huwshimi> wallyworld: please post caffeinated beverages
[04:54]  * wgrant renames PillarObserverPolicies to AccessPolicies.
[04:55] <wgrant> Considered VisibilityPolicy, but that's almost Soyuz-long...
[04:55] <wallyworld> huwshimi: i agree with your thoughts. my preference was to hide the link(s).
[04:57] <huwshimi> wallyworld: Right, I don't fully understand the situation, but it seems like they can never interact with those links if a bug is private so they should be hidden
[04:58] <wallyworld> huwshimi: sort of. it's more that there are already bug tasks on the bug for other targets and so you can't go and associate the bug with something else as well
[04:58] <wallyworld> since this will allow private info to leak
[04:58] <huwshimi> wallyworld: oh
[04:59] <wallyworld> does that change things?
[04:59] <huwshimi> wallyworld: I'm not sure, it might be a situation for some explanation
[05:00] <wgrant> (for now, but we are moving to removing those links for public bugs too eventually)
[05:00] <wallyworld> yes, and it's not like the user can readily "fix" the situation to make those unallowed links valid
[05:01] <wgrant> They can make the bug public :)
[05:01] <wallyworld> sure
[05:01] <wallyworld> but that goes against the intent
[05:04] <wgrant> But we probably need to somehow make it clear that the links aren't just randomly missing from some bugs.
[05:05] <huwshimi> ugh I can't get make schema to work
[05:05] <wgrant> Oh?
[05:05] <huwshimi> "psycopg2.ProgrammingError: function ftiupdate() does not exist"
[05:06] <wgrant> Have you run launchpad-database-setup on this machine before?
[05:06] <huwshimi> wgrant: No
[05:06] <wgrant> utilities/launchpad-database-setup
[05:06] <huwshimi> wgrant: unless it got run during the setup
[05:07] <wgrant> It's not run automatically, no.
[05:07] <wgrant> It's fairly destructive :)
[05:07] <StevenK> utilities/launchpad-database-setup $USER
[05:08] <huwshimi> thanks
[05:09] <wallyworld> wgrant: the hard bit is to make it cleat that "links aren't randomly missing" in a concise way on the gui. maybe they should be disabled rather than hidden then
[05:11] <wgrant> StevenK: Never recommend that directly.
[05:11] <wgrant> StevenK: The username is an unobvious argument for a reason.
[05:13] <StevenK> Aw
[05:13] <StevenK> I just run it
[05:13] <StevenK> But I'm pretty clear on what it does and why
[05:14] <wgrant> Yes.
[05:14] <wgrant> But new people are not.
[05:16] <huwshimi> wallyworld: this is what I get: http://i.imgur.com/Nf7Bq.png
[05:16] <wgrant> Hah.
[05:16] <wgrant> Which browser?
[05:16] <wallyworld> huwshimi: hmmm. that looks different to mine
[05:17] <wgrant> It's the opposite.
[05:17] <wgrant> The status icon is too high.
[05:17] <wgrant> The target one is just right.
[05:17] <wallyworld> i'm using ff 7.01
[05:17] <huwshimi> wallyworld: I'm using chromium of some non-descript version number
[05:18] <wallyworld> bollocks
[05:18] <huwshimi> wallyworld: 14.0.835.202 (Developer Build 103287 Linux)
[05:18] <wallyworld> so do we hack in css corrections for browser differences? surely not :-(
[05:24] <huwshimi> wallyworld: Where in the html did you add the new <a>?
[05:25] <poolie> lifeless, https://code.launchpad.net/~mbp/rabbitfixture/rabbit-startup/+merge/80174
[05:25] <wallyworld> huwshimi: after the span i think. let me check
[05:25] <huwshimi> wallyworld: This is what mine looked like: http://paste.ubuntu.com/717578/
[05:26] <wallyworld> huwshimi: mine went after the div but before the span
[05:26] <wallyworld> whereas yours in inside the div
[05:26] <wallyworld> the div pertains to the edit widget hence i put it outside that
[05:27] <huwshimi> wallyworld: oh right
[05:27] <wallyworld> not sure if that will matter
[05:27] <wallyworld> in terms of affecting layout
[05:28] <huwshimi> wallyworld: wait, where?
[05:29] <huwshimi> wallyworld: Do you want to paste it?
[05:29] <wallyworld> huwshimi: here's the tales, which i've dome now that i have it working for real https://pastebin.canonical.com/5478
[05:30] <huwshimi> wallyworld: Was that meant to go to me?
[05:31] <wallyworld> yes, sorry, i can do html also
[05:31] <wallyworld> just a sec
[05:31] <huwshimi> wallyworld: What should I be looking at from that query?
[05:32] <wallyworld> huwshimi: it's template which is turned into html, here's the html https://pastebin.canonical.com/54783/
[05:34] <huwshimi> wallyworld: right, but that first paste was the results of a db query, I'm assuming that's not what you intended on pasting
[05:35] <wallyworld> huwshimi: ah, right. cut and paste error. one digit missing https://pastebin.canonical.com/54782/
[05:35] <wallyworld> sorry
[05:36] <huwshimi> wallyworld: Ah :)
[05:36] <huwshimi> wallyworld: I was very confused
[05:36] <wallyworld> :-)
[05:39] <huwshimi> wallyworld: What happens if you apply "vertical-align: middle;" to both of the icons?
[05:39]  * wallyworld tries that
[05:41] <wallyworld> huwshimi: trouble it, the edit icon is a <button>
[05:41] <wallyworld> and addign that style makes it disappear
[05:42] <wallyworld> at least it disappeared for me
[05:42] <wallyworld> the html is <button class="lazr-btn yui3-activator-act"> Edit </button>
[05:43] <huwshimi> wallyworld: that's strange, it worked for me
[05:44] <wallyworld> hmmm. could be a firebug thing
[05:44] <wallyworld> i'll add that to the lazr-js css and see
[05:49] <wallyworld> huwshimi: seems to have helped a bit http://people.canonical.com/~ianb/bugtask-icons-1.png
[05:51] <wallyworld> huwshimi: the css turns out as https://pastebin.canonical.com/54784/
[05:53] <huwshimi> wallyworld: how do they line up with other icons on the page?
[05:54] <wallyworld> huwshimi: as per the screenshot, they look a little higher than the other similar icons in that row (which have no vertical alignment style) but at least they appear consistent to each other
[05:55] <wallyworld> perhaps we need to add that vertical alignment style to all such icons
[05:55] <huwshimi> wallyworld: I believe the vertical-align: middle is on all the others
[05:56] <wallyworld> huwshimi: ah, so it is
[05:56] <wallyworld> so if i add that style to the lazr activator button css it seems to help at least
[05:58] <wallyworld> huwshimi: thanks for the help. so you are happy for the delete icon to be rendered where it is (to the right of the change target icon)?
[05:59] <huwshimi> wallyworld: yeah I guess that makes sense
[05:59] <wallyworld> i can't think of a better place. the icon will only be there for those tasks which the user has permission to delete
[05:59] <wallyworld> so some will have it, others won't
[06:29] <wgrant> lifeless: Do we want an abstract product|distribution table as well?
[06:29] <wgrant> (in addition to the abstract bug/branch/someotherartifact table)
[06:29] <wgrant> I think you might have done some analysis around this.
[06:40] <lifeless> wgrant: IBugContextPillars ?
[06:40] <micahg> wow, Bug #878909 threw up a red flag, wallyworld, who can do this sort of thing?
[06:40] <_mup_> Bug #878909: allow users to delete bugtasks using the web UI <bugs> <disclosure> <privacy> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/878909 >
[06:41] <wgrant> micahg: At present nobody. We plan to open it up to pillar owners, and possibly bug supervisors if my objections are defeated.
[06:41] <wallyworld> micahg: lp admins, project owners. i'll have to double check who else
[06:42] <micahg> wallyworld: wgrant: excellent assuming wgrant isn't overruled, acceptable if he is, it might be good to clarify in the bug in case anyone else sees it though :)
[06:42] <lifeless> micahg: why? whats the concern ?
[06:42] <wallyworld> micahg: it's also behind a feature flag
[06:42] <micahg> lifeless: regular users deleting bug tasks
[06:42] <lifeless> micahg: how is that worse than regular users adding them ?
[06:43]  * lifeless speculates
[06:43] <wallyworld> micahg: permissions are: lp admins, pillar owners, pillar bug supervisors
[06:43] <micahg> lifeless: irreversable?
[06:43] <wallyworld> and only if the ff is on
[06:43] <lifeless> micahg: add a new task set the old status
[06:43] <lifeless> micahg: thats pretty reversable
[06:43] <wgrant> Hah, it seems I have been defeated :)
[06:43] <wgrant> Ubuntu bug supervisors possibly shouldn't have this power, but I guess we'll see.
[06:44] <lifeless> perhaps we should let anyone delete invalid tasks
[06:44] <wallyworld> wgrant: that's what the ff is for - to allow us to get that bit sorted
[06:44] <micahg> lifeless: it's harder to notice a missing bug task
[06:44] <wgrant> wallyworld: Yep, that's why I recommended it.
[06:44] <lifeless> micahg: we'll send a notification out
[06:44] <wgrant> But I didn't think we were doing bug supervisors in the initial pass.
[06:44] <lifeless> however, implementation wise this is real deletes, not a status-that-hides-the-bug
[06:44] <wallyworld> only if the ff is on
[06:45] <micahg> lifeless: indeed, but a wrong status/bug task is visible in the bug, a missing one would only be visible in the history/e-mail
[06:45] <lifeless> (because this is needed to let folk cleanup private bugs before the next stage, where we disable private bugs w/multiple pillars
[06:45] <wallyworld> there are a lot of invalid bug tasks that have been assigned to the null project, no?
[06:45] <wallyworld> only because we couldn't delete them
[06:46] <lifeless> yes, but if we had a 'deleted' state they wouldn't be there either
[06:46] <lifeless> and it would be more reversible
[06:46] <lifeless> safer in a lot of ways
[06:46] <wallyworld> lifeless: branch deletion is also permanent
[06:46] <lifeless> wallyworld: the sky is blue
[06:46] <micahg> lifeless: I don't have a problem if it's limited, we can warn Ubuntu bug control members more sternly about it, but open to anyone sounds like trouble, someone disagrees with won't fix, delete and create a new bug task
[06:46] <wgrant> Only the branch owner can delete branches.
[06:46] <wallyworld> although in general i agree with soft deletes for model artifacts
[06:47] <wallyworld> so branch owners can still make mistakes
[06:47] <lifeless> micahg: its not open to anyone, and if we did open to anyone I'm pretty sure we would status lock it (e.g. delete invalids only)
[06:47] <wgrant> I think hard deletes are almost always a mistake.
[06:47] <wgrant> Except this time we're trying to fix a broken model design from 2004.
[06:47] <lifeless> wallyworld: anyhow, its moot: we need hard deletes for *some bugs* *now*
[06:48] <wallyworld> yeah, hence it was done as a hard delete and not a soft delete
[06:48] <lifeless> wallyworld: we may want soft deletes once the migration is over, note that soft deletes have further dev ramifications
[06:48] <wallyworld> we can revisit later
[06:48] <wgrant> Once we have bugs comfortably single-target in a couple of years, we no longer need deletes of any kind.
[06:48] <wallyworld> soft deletes will have a *lot* impact on model queries etc
[06:48] <lifeless> wallyworld: not really
[06:48] <wgrant> It's just the same as a status search.
[06:48] <wgrant> Which we always do anyway.
[06:49] <lifeless> wallyworld: we already have sets for interesting-default status and custom-set-of-status
[06:49] <wgrant> It is a rare query that doesn't exclude Invalid.
[06:49] <wallyworld> why? *every* query will need an extra "is not deleted" condition
[06:49] <wgrant> status NOT IN (invalid, fixreleased, deleted)
[06:49] <nigelb> Hrm, is jtv not working today?
[06:49] <lifeless> wallyworld: only if you implement deleted as a separate bit
[06:49] <lifeless> wallyworld: which is an option, but not a requirement
[06:49] <wallyworld> which one would normally o, no?
[06:49] <wallyworld> status != deleted
[06:50] <wallyworld> semantically sifferent
[06:50] <lifeless> wallyworld: I think many folk would argue that deleted is a lifecycle state for a bug task, rather than separate to status
[06:50] <wgrant> Deleted is a special case of Invalid.
[06:50] <wgrant> Isn't it?
[06:50] <wallyworld> then they are wrong :-P
[06:50] <wallyworld> not in my view, but anyways, it's moot for now
[06:50] <wgrant> "Deleted" == "So invalid that GTFO"
[06:51] <wallyworld> even if it could be argued that way for bug tasks (which I'm not agreeing with), it doesn't generalise to other model objects
[06:52] <wallyworld> since  not everything else necessarily has a lifecycle status attribute
[06:54] <wgrant> A "deleted" flag is just a lifecycle status attribute that happens to be a boolean.
[06:55] <wallyworld> perhaps. but i view it as subtlely different. it's just imo.
[06:55] <poolie> allenap, review on https://code.launchpad.net/~mbp/rabbitfixture/rabbit-startup/+merge/80174  please?
[06:55] <wallyworld> existence vs state
[07:00] <wallyworld> wgrant: i can't quite see how "if len(bug.affected_pillars) > 1" is wrong. you say that it prevents adding *any* task but that's not true if the bug tasks are all for the same pillar
[07:01] <wgrant> wallyworld: Sure, but say I have a private security bug affecting Ubuntu and Debian, and I want to fix it in Ubuntu.
[07:01] <wgrant> Unless I have the new task deletion superpower, I can't fix it in Ubuntu, because I can't target it to the series.
[07:02] <wgrant> We should forbid making the bug more broken.
[07:02] <wgrant> But adding another task for an existing pillar is not making it more broken.
[07:02] <wgrant> Because brokenness = number of pillars - 1.
[07:03] <wallyworld> wgrant: so you want to remove that check entirely i think
[07:03] <wgrant> Yes.
[07:03] <wallyworld> ok
[07:03] <wgrant> I think of those three checks, on the third is useful.
[07:03] <wgrant> s/on/only/
[07:04] <wallyworld> ok. so long as you are happy with just the third, i'll get rid of the others
[07:04] <wgrant> I believe the first two are excessive, and the bits that aren't excessive are redundant.
[07:05] <wallyworld> ok
[07:05] <wallyworld> i'll redo and you can double check
[07:05] <wgrant> Thanks.
[07:10] <poolie> >> A lot of the feedback was very complimentary to the infrastructure (Launchpad, Wiki, IS
[07:10] <poolie> facilities etc) that Canonical provides to help Ubuntu contributors to do their work.
[07:10] <poolie> from the recent developer survey
[07:10] <poolie> way to go robot
[07:11] <nigelb> \o/
[07:11] <nigelb> Launchpad bug tracking is pretty awesome, despite all its faults.
[07:11] <nigelb> And the timeout work + less email work has everyone quite happy.
[07:11] <wgrant> It's getting more awesome :)
[07:11] <nigelb> Indeed.
[07:11] <nigelb> I'm waiting to see the end of deryck's squad's work.
[07:11] <wgrant> First major improvements in years, apart from the subscription work.
[07:12] <nigelb> if you guys can pull of what mrevell mentioned in his email..
[07:14] <poolie> full survey http://t.co/sdyJKAnO
[07:14] <poolie> >> Here and elsewhere in the survey the patch pilot programme was specifically highlighted as
[07:14] <poolie> a successful initiative.
[07:14] <poolie> go me.
[07:15] <poolie> and all the people who did the work
[07:15] <poolie> :)
[07:15] <nigelb> \o/
[07:15] <nigelb> The patch pilot idea was inspired by bzr right?
[07:16] <StevenK> Yes
[07:16] <poolie> yep, after some lobbying
[07:16] <nigelb> heh
[07:16] <nigelb> Its a great idea!
[07:16] <nigelb> ohai StevenK :)
[07:17] <StevenK> Hai
[07:18] <nigelb> heh
[07:18] <nigelb> "do you feel you are able to influence the decision-making of Canonical"
[07:18] <nigelb> Never.
[07:18] <mrevell> hi
[07:18] <nigelb> Morning mrevell!
[07:19] <poolie> nigelb, yeah, that is
[07:19] <poolie> not surprising, perhaps a bit worrying
[07:20] <nigelb> Well, I wish people in the community could be part of the teams.
[07:20] <nigelb> Like, say kernel or design.
[07:20] <poolie> mm
[07:20] <poolie> especially design perhaps
[07:20] <nigelb> yeah
[07:20] <poolie> i think a lot more of the kernel work is in the open
[07:21] <nigelb> Like launchpad is intresting, because I can participate in the development along with paid employees.
[07:21] <nigelb> Some teams are less open.
[07:21] <nigelb> Espcially design.
[07:21] <nigelb> If there's a UX trained person in the community who wants to help..
[07:21] <nigelb> (I wish sladen wasn't working for Canonical :P)
[07:21] <poolie> me too :-P
[07:21] <poolie> jk
[07:22] <nigelb> heh
[07:22] <nigelb> He's the kind of person I mean, he knows what he's talking about and can give design feedback.
[07:22] <nigelb> Its still mertiocracy.
[07:24] <nigelb> Anyway, back to work :)
[07:24] <nigelb> Monday Mourning and all that.
[07:45] <adeuring> good morning
[12:57] <Ursinha> wgrant, hey, still there? :) do the daskeyboard beauties have backlight?
[12:58] <Ursinha> since I lost control I'm pondering buying myself one
[12:59]  * nigelb blinks and processes
[12:59] <nigelb> ah, right. Lost control.
[12:59] <wgrant> Ursinha: No backlight, no.
[12:59] <Ursinha> nigelb, :D
[13:00] <Ursinha> nigelb, http://www.facebook.com/photo.php?fbid=2360791707157&set=a.1738496950177.2097724.1471235315&type=1
[13:00] <Ursinha> wgrant, ah. thanks anyway :)
[13:00] <nigelb> Ursinha: I remember :)
[13:00] <nigelb> I commented or Like'd it before.
[13:01] <Ursinha> nigelb, yeah, I just wanted to make it easy for you :)
[14:18] <allenap> jelmer: Hi, I have a question about stacking. Do you have a few minutes? Someone seems to have been able to get two of their branches to stack on one another, https://answers.launchpad.net/launchpad/+question/175926.
[14:25] <allenap> abentley: Thank you for pursuing that storm fix. I haven't had time yet today - on maintenance - to do anything more, but I will as soon as I can.
[14:25] <abentley> allenap: Thanks!
[14:26] <allenap> abentley: jelmer ^ doesn't seem to be here right now, would you have time to help me with https://answers.launchpad.net/launchpad/+question/175926?
[14:29] <abentley> allenap: I'm sorry, but I haven't had anything to do with the mirroring infrastructure since the bzr team rewrote it.
[14:30] <allenap> abentley: Okay, no worries. Anyone in the bzr team in particular I should talk to, or shall I just badger all of them?
[14:31] <abentley> allenap: I don't know of anyone in particular.
[14:31] <sinzui> bac ping
[14:36] <sinzui> benji, bac, gmb, allenap: Bug #879901 need immediate fixing. ISD sees no issues on their side
[14:36] <_mup_> Bug #879901: Purchased commercial vouchers do not arrive at Launchpad <projects> <regression> <salesforce> <Canonical Salesforce:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/879901 >
[14:37] <benji> sinzui: we will look at it now
[14:38] <sinzui> benji, ISD sent me a list that confirm they have a record of my purchases on the 11, 12, 22 of this month.
[14:41] <benji> sinzui: ok, so the purchases are correctly recorded in salesforce therefore we should start by looking at the lp<->salesforce interconnect
[14:42] <sinzui> benji, exactly. The gateway port could be blocked or the query/protocol changed
[14:43] <sinzui> maybe Lp is not polling salesforce anymore
[14:43] <benji> sinzui: thanks for the verification, I'm reading voucher code to see where to get started
[14:44] <sinzui> benji, bac diagnosed the last two outages. I think He had a losa switch a process to debug to log the underlying issue
[14:44] <benji> sinzui: good to know, I'll see if he can give me a hand
[14:45] <benji> bac: are you really not in #launchpad-yellow or is my IRC client acting up?
[14:45] <sinzui> maybe bac is still travelling home
[14:48] <cjwatson> Thank goodness Launchpad isn't like this: http://thedailywtf.com/Articles/The-Query-of-Despair.aspx
[14:49] <sinzui> benji, Bug #557392 and Bug #597754 might be informative
[14:49] <_mup_> Bug #597754: Launchpad voucher redemption fails with unactivated vouchers <lp-registry> <oops> <qa-ok> <Canonical Salesforce:Fix Released by jamesj> <Launchpad itself:Fix Released by bac> < https://launchpad.net/bugs/597754 >
[14:50] <benji> thanks sinzui, taking a look
[14:51] <sinzui> benji, James confirmed my vouchers are active
[14:51] <benji> sinzui: that would seem to rule out a reoccurrance of bug 597754 then
[14:51] <_mup_> Bug #597754: Launchpad voucher redemption fails with unactivated vouchers <lp-registry> <oops> <qa-ok> <Canonical Salesforce:Fix Released by jamesj> <Launchpad itself:Fix Released by bac> < https://launchpad.net/bugs/597754 >
[14:52] <sinzui> I agree. the other bug looks promising
[14:55] <jelmer> hi allenap
[14:56] <allenap> jelmer: I've just spoken to mgz in #bzr, thanks for getting back to me though.
[14:57] <jelmer> allenap: ah, cool
[15:10] <benji> sinzui: do you have any hints as to where the proxy's logs are?  I gather from 557392 that the proxy runs on niobium, but I don't see that machine's logs in /srv/launchpad.net-logs/production/ on chinstrap
[15:10] <sinzui> hmm
[15:19] <nigelb> heh
[15:19] <nigelb> http://thedailywtf.com/Articles/The-Query-of-Despair.aspx
[15:39] <allenap> Are there any Soyuz Gods in here who can help with https://answers.launchpad.net/launchpad/+question/175403?
[15:41] <nigelb> allenap: I thought all those gods were in australia? :)
[15:42] <allenap> nigelb: I think you're right. I'm hoping that one of them has insomnia and an urge to check IRC.
[15:43] <nigelb> :)
[15:43] <nigelb> That does happen way too often.
[16:18] <cjwatson> allenap: It's really a question about the platform, not a Soyuz question.  I've answered.
[16:18] <allenap> cjwatson: Thank you :)
[16:18] <cjwatson> (Although I suppose "no, we won't manually set up symlinks in /usr/bin for you" involves a degree of Soyuz knowledge, but. ;-) )
[16:57] <mrevell> Night all
[17:29] <nigelb> Ursinha: You might find this quote interesting "Chuck Norris's keyboard doesn't have a Ctrl key because nothing controls Chuck Norris." :)
[17:31] <Ursinha> nigelb, ha!
[17:31] <Ursinha> :P
[17:32] <nigelb> :D
[17:52] <mtaylor> sinzui: I bugged you the last time someone merged their account and wound up with two open ids, didn't I?
[17:56] <mtaylor> well, in any case, we just had someone else merge accounts and wind up with SSO not working properly for him: https://answers.launchpad.net/launchpad/+question/176031
[18:12] <sinzui> mtaylor, okay
[18:13] <sinzui> I think we need to ensure a bug is reported and a maintenance is is working to fox the root cause.
[18:13] <sinzui> I will do that no
[18:13] <sinzui> now
[18:15] <mtaylor> sinzui: cool. thanks!
[18:15] <mtaylor> sinzui: I thought you might have had a thought on the root cause there
[18:15] <mtaylor> :)
[18:27] <lifeless> morning
[18:41] <lifeless> benji: can has review?
[18:41] <lifeless> https://code.launchpad.net/~lifeless/python-oops-tools/bug-879309/+merge/80175
[18:42] <benji> lifeless: since you ask so nicely, sure
[18:42] <lifeless> benji: :) thanks!
[18:50] <lifeless> sinzui: on merge do we intend to keep all the identities active indefinitely ?
[18:51] <lifeless> sinzui: what do we do with the alias that we used to offer ourselves (https://launchpad.net/~lifeless used to (still does?) work as an openid thingy)
[18:52] <lifeless> sinzui: I ask because there is another bug elsewhere talking about persistent identifiers for users, and merge will affect that too
[18:52] <benji> lifeless: I'm done with the review.  Only one small bikeshed.
[18:53] <lifeless> :) thanks
[18:55] <sinzui> lifeless, yes, we keep the ids forever to ensure no matter which identity SSO uses continues to work
[18:55] <sinzui> lifeless, i think is is largely because we do not have a mechanism to sync with Ubuntu's SSO
[18:56] <lifeless> sinzui: yah, thats in fact the other bug I'm thinking of :)
[18:56] <lifeless> sinzui: well, kinda
[18:57] <lifeless> sinzui: anyhow, can you check my logic here (not related to your bug):
[18:57] <lifeless>  - we allow multiple openids to login to a single user
[18:57] <lifeless>  - merging just unions them (in theory)
[18:57] <lifeless>  - openids can not be deleted by the user?
[18:58] <sinzui> lifeless, yes, These are issue I brought up in my email 14 months ago to the list. The foundations team was working in an adhoc fashion to solve the defects in the SSO split
[18:58] <lifeless>  -> openids could be used as a static persistent identifier in the SOA?
[18:58] <lifeless> step 3 I'm not sure of
[18:58] <sinzui> stub was working with a lot of distractions and was asking for help to determine which bugs really needed to be addresses
[18:58] <sinzui> addressed
[19:47] <flacoste> benji: do you know why wgrant put bug #828572 back in progress?
[19:47] <_mup_> Bug #828572: bugs are marked incomplete_with_response if users or scripts change the status / tags immediately after setting the status <escalated> <qa-ok> <ubuntu-qa> <Launchpad itself:In Progress by benji> < https://launchpad.net/bugs/828572 >
[19:48] <benji> flacoste: I'm wondering the same thing; I figured that if I didn't see him by the time I EODed I'd email him to find out
[19:49] <benji> he should be around in an hour or so
[20:07] <lifeless> have we finished the migration and deleted the old query code entirely?
[20:28] <benji> lifeless: yep, the migration is done (there were 5 unmigrated records last week that have now been fixed) and my branch switches to query on the new with/without response flavors of incomplete
[20:29] <lifeless> benji: so your branch can close that bug :)
[20:30] <benji> lifeless: I think so.  I'd like to know why wgrant reopened it though.  I don't want to get in a game of status tennis.
[20:30] <lifeless> of course :)
[20:30] <lifeless> wgrant: ^ :)
[20:38] <flacoste> lifeless: https://bugs.launchpad.net/launchpad/+bug/314432
[20:38] <_mup_> Bug #314432: It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed <api> <dhrb> <lp-bugs> <platform-blocker> <rls-mgr-p-tracking> <ubuntu-qa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/314432 >
[20:39] <flacoste> lifeless: https://bugs.launchpad.net/launchpad/+bug/857109
[20:39] <_mup_> Bug #857109: Cannot have a bug targetted only to an old series <Launchpad itself:Triaged> < https://launchpad.net/bugs/857109 >
[21:02] <benji> wgrant: hi, you around?
[21:56] <lifeless> sinzui: hey, if you have some time, I'd love to catch up
[22:01] <sinzui> lifeless, I may have time after my standup that always goes longer than 15 minutes
[22:02] <wgrant> benji: I didn't realise it was actually finished. I thought just the initial schema work had been done.
[22:03] <benji> wgrant: ok, cool; I'll update the bug (and add a comment so the stakeholders can verify that the behavior is what they want)
[22:03] <lifeless> sinzui: that would be cool
[22:39] <wgrant> lifeless: lol
[22:39] <wgrant> That's data corruption?
[22:40] <wgrant> You'd better not look at Soyuz...
[22:40] <lifeless> wgrant: binaries with no source records (and not deliberately mangled) yes
[22:40] <lifeless> wgrant: look on the bright side, we have to start somewhere
[22:43] <sinzui> StevenK, bug 784596 is now in scope
[22:43] <_mup_> Bug #784596: UI implies open/delegated teams can have PPAs <confusing-ui> <disclosure> <ppa> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/784596 >
[22:53] <StevenK> sinzui: Just thinking about it, I don't think open teams have the create PPA link any more
[22:54] <sinzui> That would be excellect
[22:54]  * wallyworld stabs unity and all the duplicate icons that have just appeared on the launcher
[22:55] <StevenK> sinzui: I will investigate, in either case.
[22:57] <sinzui> StevenK, lp.registry.interfaces.person.team_subscription_policy_can_transition does all sanity checking. It is used by the field to guarantee sanity. It must learn about subscriptions to private artefacts
[23:00] <lifeless> wgrant: you asked yesterday about a new table
[23:00] <lifeless> wgrant: i think we failed to discuss
[23:00] <wgrant> lifeless: We did. I must have become distracted with something.
[23:00] <wgrant> Possibly the factory being pathetically slow.
[23:01] <lifeless> when you're off your call; and I've had a brief catchup with curtis, we can talk
[23:01] <wgrant> The call is done. sinzui is setting dinner in motion, then talking to you.
[23:01] <lifeless> ok
[23:01] <lifeless> so until he arrives ..
[23:02] <lifeless> you were asking about a denormed table the contents of which would be something like (product|distro) which I interpreted as ICanHasBugTaskAndArePillars
[23:02] <wgrant> Right.
[23:02] <lifeless> flacoste and I were talking about seriesonlybugtasks
[23:02] <wgrant> I currently have an abstract artifact table, but not one for pillars.
[23:02] <lifeless> it may get scheduled
[23:02] <lifeless> via maintenance
[23:03] <wgrant> Eww.
[23:03] <lifeless> one of the impacts is that the fields in bugtask would be reduced - drop product and distro
[23:03] <wgrant> I think it should be done as part of the larger IssueTracker rework.
[23:03] <wgrant> At the same time as single-targeting bugs.
[23:03] <lifeless> wgrant: single targeting bugs isn't [currently] a desired end-state
[23:03] <wgrant> (one Product/Distribution/DistributionSourcePackage + its series)
[23:03] <wgrant> I think it is.
[23:03] <wgrant> You just don't know it yet.
[23:03] <lifeless> wgrant: I know you hold a different opinion
[23:04] <lifeless> wgrant: I think there are significant issues clustered around that, around work items, and around conversations.
[23:04] <lifeless> I'm not willing to say you are wrong... but I'm also not willing to say you are right.
[23:04] <wgrant> And I think pushing for series-only tasks before while we have NFI what we're doing around tasks is a big mistake.
[23:05] <lifeless> well, the idea is to have product do some user research
[23:05] <lifeless> validate or invalidate the idea as an incremental improvement
[23:05] <wgrant> As long as they take the user input with roughly 10 megatonnes of salt, sure.
[23:06] <lifeless> mmm, so for a quick update this has turned into a lot of hyperbole
[23:06] <lifeless> Lets talk later
[23:27] <sinzui> Hi lifeless. I am on skype
[23:28] <lifeless> hi
[23:59] <lifeless> wgrant: ok, want to talk about this now?