| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| lifeless | mpt: hi | 21:03 |
|---|---|---|
| mpt | hi ho | 21:03 |
| lifeless | mpt: can you confirm, how do you believe Opinion operates vs WontFix ? | 21:03 |
| mpt | lifeless, do you mean, how do I believe people use it, how do I believe people should use it, or how do I use it? | 21:04 |
| lifeless | how does launchpad treat it | 21:04 |
| lifeless | you say 'reports that are currently "Opinion" can't just migrate to "Won't Fix", because that would hide many reports that the developers considered to be valid. ' | 21:04 |
| lifeless | but Opinion bugs are already closed as far as Launchpad is concerned. | 21:05 |
| lifeless | This leaves me a little confused. | 21:05 |
| mpt | lifeless, I went solely on their comments when they set the status. Maybe they don't realize Launchpad is treating it as closed. | 21:07 |
| lifeless | thanks | 21:08 |
| lifeless | that lets me understand enough to reply sensibly :) | 21:08 |
| mpt | lifeless, this is something I've been meaning to do ever since John Lea explained in a UDS session that "Opinion" doesn't mean "Won't Fix", it means "we know this is an issue and we're going to look at it later". | 21:09 |
| lifeless | yeah, it means the same as 'invalid' and 'wontfix' as far as Launchpad is concerned. | 21:09 |
| mpt | Unfortunately I haven't found a citation for that, it's just my personal memory, but it turns out to match up with how the developers often use it. | 21:09 |
| mpt | If Launchpad itself treats "Opinion" identically to "Won't Fix", that in itself is a reason they shouldn't both exist -- but then the same is true for "Invalid". :-) | 21:12 |
| lifeless | exactly | 21:12 |
| mpt | (I know BjornT explained once that there is a small difference in behavior between "Won't Fix" and "Invalid", but I don't remember what it is.) | 21:12 |
| lifeless | thats why all the refresh-of-bugs proposals include consolidating those things | 21:12 |
| lifeless | there is no such difference | 21:12 |
| mpt | It wasn't to do with normal bug searching, it was something more esoteric | 21:13 |
| lifeless | I believe the current consensus is that LP should let folk choose the behaviour they want and allow semi-arbitrary explication | 21:13 |
| lifeless | e.g. want the bug not shown to developers by default - thats 'closed', and whether it was fixed/rejected/might come back later is data the bug tracking system doesn't need to really know about | 21:14 |
| lifeless | this suggests two core states for bugs - open vs closed, and a separate workflow layer - 'next action by: [Triage/developer/architect|design/qa]' | 21:14 |
| lifeless | mpt: there may be an ACL on whether a bug can be reopened, I'm not sure. | 21:16 |
| lifeless | mpt: (but I'm fairly sure invalid and wontfix are identical there) | 21:16 |
| mpt | lifeless, "Next action by:" = assignee | 21:18 |
| mpt | There are seventy-odd bugs assigned to me right now, and all of them I'll reassign/deassign when done, because they're assigned to me only to do the design on them | 21:18 |
| lifeless | mpt: there is handwaving involved :) | 21:18 |
| mpt | When Google Code Hosting started out it had only "Open" vs "Closed", though it had better tags | 21:19 |
| lifeless | mpt: consider the case when e.g. mvo is tasked with a bug, but decides he needs more input from the reporter; how does reporter know to hand it back to mvo? [And how do they get the privileges to do so] | 21:19 |
| mpt | I think it may have expanded since then | 21:20 |
| lifeless | mpt: it would be nice to avoid losing datum (that mvo is tasked with the bug) when a temporary handoff is needed but mvo is *still responsible*. | 21:20 |
| mpt | lifeless, https://dev.launchpad.net/IssueTracker#Delegation | 21:20 |
| lifeless | yeah | 21:20 |
| lifeless | just noting that this != assignee | 21:21 |
| mpt | So you've just made me realize a flaw in my mental model | 21:21 |
| lifeless | or at least, its not as trivial as saying that | 21:21 |
| lifeless | mpt: cool! | 21:21 |
| mpt | That one status == one behavior in Launchpad | 21:21 |
| mpt | Let's say you find a bug report that was marked as "Closed" without comment. You download the new version and the bug still exists. Should you reopen it? | 21:22 |
| lifeless | so my goal here is to identify the minimal set of primitives in the system that will let folk build robust, automatable processes on top of them. Less primitives => lower learning curve and smaller UI footprint. | 21:23 |
| mpt | If it was marked as "Declined", no, the developers decided the behavior should stay as it is. If it was marked as "Fixed", yes you should, because they meant to fix it but didn't fix it properly. | 21:23 |
| mpt | So that's a difference in behavior, just not inside Launchpad itself. | 21:23 |
| mpt | The only way you could tell that from "Closed" was if the developer commented to explain which kind of Closed it is, and they shouldn't have to do that. | 21:24 |
| lifeless | yeah. Some developers might prefer a separate bug report in those situations, because it might be a different root cause or something. But that seems outside LP's purview. | 21:24 |
| lifeless | I think one key thing we need to do is get away from the model that a bug report is roughly equivalent to a mailing list | 21:25 |
| lifeless | it frames things poorly | 21:25 |
| mpt | All of that to say that I think it's more efficient to have "Fixed" (= Fix Committed + Fix Release) and "Declined" (= Invalid + Won't Fix + Opinion + Expired) as separate statuses | 21:25 |
| mpt | +d | 21:27 |
| lifeless | I note an assumption in your reasoning | 21:28 |
| mpt | do tell | 21:28 |
| === mwhudson_ is now known as mwhudson | ||
| lifeless | that status U ('open', 'closed') implies a comment is needed to differentiate between ('fixed', 'declined') | 21:29 |
| lifeless | if you imagine the current status rows | 21:29 |
| lifeless | which has a wide status field and a wide importance field | 21:29 |
| mpt | lifeless, re. making it less like a mailing list, absolutely -- that's why I reported bug 1734, bug 520405, and bug 555293, for example | 21:30 |
| _mup_ | Bug #1734: Bug discussion is append-only and cannot be gardened <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1734 > | 21:30 |
| _mup_ | Bug #520405: Canned "this is a duplicate" response wastes time - launchpad itself could explain about the duplicate nature and process (and avoid storing the redundant copies of this message) <degreasing> <lp-bugs> <story-better-bug-notification> <Launchpad itself:Triaged> <Launchpad Greasemonkey Scripts:Triaged> < https://launchpad.net/bugs/520405 > | 21:30 |
| _mup_ | Bug #555293: Canned "This bug did not have a package" reponse wastes time <degreasing> <lp-bugs> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/555293 > | 21:30 |
| mpt | lifeless, I suppose there are other ways you could tell the difference between Fixed and Declined -- for example, whether the trunk branch or a release ended up associated with the report. But Launchpad would still need to do work to get from that to a clear answer to the question, "Should I reopen this if I still see the bug 47 days later?" | 21:31 |
| _mup_ | Bug #47: Add -F (Force) and -p (sourcePackage) flags to nicole <lp-foundations> <Launchpad itself:Invalid> < https://launchpad.net/bugs/47 > | 21:31 |
| * mpt pats _mup_ on the head | 21:32 | |
| lifeless | mpt: do you think users will listen to such a hint? (where users could be users of LP or users of Ubuntu or whatever) | 21:32 |
| lifeless | mpt: for instance, I tell folk that interact with my projects to never ever reopen a bug. I want them to always open a new one, no matter the resolution of the prior one, unless they know a-priori its the same root cause. | 21:33 |
| lifeless | (Which is often impossible without being deeply into the code) | 21:34 |
| lifeless | mpt: I do this because I can only merge bug reports effectively, not split. | 21:34 |
| mpt | lifeless, oh, sorry, I'm using "reopen" as short-hand for "reopen if the existing report is wieldy, re-report if it isn't" | 21:35 |
| lifeless | how much easier or useful would this make LP? | 21:35 |
| mpt | For example, last week bug 949414 was marked fixed, but it still occurred for me, and so (for the reasons you just gave) I re-reported it as bug 969076 | 21:35 |
| _mup_ | Bug #949414: Some GTK+3 events are not emitted when using a touchpad (but are with a mouse) <rls-mgr-p-tracking> <rls-p-tracking> <elementary OS:Triaged> <GTK+:Fix Released> <gtk+3.0 (Ubuntu):Fix Released> <gtk+3.0 (Ubuntu Precise):Fix Released> < https://launchpad.net/bugs/949414 > | 21:36 |
| _mup_ | Bug #969076: With touchpad, non-first menu items don't highlight and submenus don't open until clicked <gtk+3.0 (Ubuntu):Confirmed> < https://launchpad.net/bugs/969076 > | 21:36 |
| lifeless | (this == telling folk whether to reopen or not via LP status data) | 21:36 |
| mpt | lifeless, I think it's very useful, but maybe I work around the sort of reports where correct behavior is more debatable than it would be in other kinds of software, so it would be harder to tell whether a Closed report was fixed or not | 21:38 |
| mpt | I don't know that you could easily measure how useful the distinction is, because if sequel bug reports reference the original, they do so as plain text | 21:39 |
| lifeless | we will be able to model that in future | 21:50 |
| mpt | (And even if you managed to measure it, you'd have a post hoc ergo propter hoc problem: you'd know only how often people reopened/re-reported a bug *after* it was marked fixed, it wouldn't tell you how often they did so *because* it was marked fixed.) | 21:50 |
| lifeless | did you know that Fix Released bugs are not reopenable except by bug controllers | 21:51 |
| lifeless | this was done because too many Fix Released bugs were reopened and developers wanted new bugs. | 21:51 |
| lifeless | s/too many/sufficiently many/ | 21:51 |
| cjwatson | splitting bugs in LP wouldn't necessarily be horribly difficult | 21:51 |
| cjwatson | doing it with total flexibility is hard, but fork-history-at-this-point is relatively simple | 21:52 |
| mpt | lifeless, I have occasionally known, when I re-report a bug that was mistakenly marked fixed in a project I don't otherwise contribute to. But usually I am in a state of having forgotten that. :-) | 21:52 |
| cjwatson | though ideally it'd be more like "take this set of comments and hive off to new bug" | 21:52 |
| lifeless | mpt: so I think we have data that developers do care about reopen/open new - sufficiently strongly that LP implements a policy supporting 'always open new' | 21:53 |
| lifeless | cjwatson: its not rocket science, as they say, but it does need work - and needs to handle dealing with things like bug 1. | 21:53 |
| _mup_ | Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice Productivity Suite:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <metacity:In Prog | 21:53 |
| mpt | lifeless, okay, but that's still a side issue from the general point of how a tester can tell *whether* a bug was supposed to have been fixed or not. | 21:53 |
| cjwatson | wontfix/invalid> I certainly implemented something that made ACLs on those different | 21:53 |
| lifeless | mpt: I think its totally different | 21:54 |
| cjwatson | which Contributions tells me was bug 294846 | 21:54 |
| _mup_ | Bug #294846: Setting to Won't Fix is ACLed but unsetting it isn't <lp-bugs> <qa-ok> <ubuntu-qa> <Launchpad itself:Fix Released by cjwatson> < https://launchpad.net/bugs/294846 > | 21:54 |
| mpt | lifeless, what is totally different? | 21:54 |
| lifeless | mpt: there are two cases where someone other than the developer who closed the bug will encounter it: a) they go looking for it and b) they encounter it spontaneously. | 21:54 |
| lifeless | mpt: case a) is software testers - whether crowd sourced or staffed. They *know* that it was meant to be fixed - that is why they are going looking for it. | 21:55 |
| lifeless | mpt: case b) *sometimes* happens to people that are software testers but also happens to people that are not. | 21:55 |
| lifeless | mpt: why should case (b) be treated differently depending on whether the person experiencing it is a software tester or not ? | 21:56 |
| mpt | lifeless, I disagree that software testers necessarily know whether a bug was meant to be fixed. | 21:56 |
| lifeless | mpt: in case (a) they always do, because its been handed to them to verify that it is fixed. | 21:57 |
| mpt | lifeless, that's only one of the things testers do, though. Often they also report things that seem wrong to them. Often they're right. :-) | 21:58 |
| lifeless | mpt: indeed, but that is case (b) | 21:58 |
| mpt | I don't understand what you mean by "case (b) be treated differently depending on whether the person experiencing it is a software tester or not". | 21:58 |
| lifeless | mpt: AIUI you are arguing that a software tester that spontaneously encounters a previously reported & closed bug needs to take different action depending on whether the bug was closed-fixed or closed-declined | 22:00 |
| lifeless | mpt: clearly non-testers cannot take different actions, because they are prohibited from reopening closed-fixed bugs | 22:00 |
| mpt | lifeless, I'm arguing that *anyone* in that situation should do that. | 22:00 |
| lifeless | mpt: but developers don't want them to be able to | 22:00 |
| mpt | What? | 22:00 |
| lifeless | mpt: reopening fixed bugs is a privileged operation | 22:01 |
| lifeless | s/fixed/'fixed' | 22:01 |
| mpt | lifeless, so we're still side-tracked. Once again, this is nothing to do with whether they have permission to reopen the bug report or whether they make a new bug report. | 22:01 |
| lifeless | I'm not sure I follow, but please continue :) | 22:02 |
| mpt | lifeless, my point in wanting Fixed and Declined to be separate is that it tells someone, who comes across the bug report and currently experiences the behavior that it complained about, whether the developers thought the complained-about behavior was correct or not. | 22:04 |
| mpt | If the developers thought the behavior was incorrect, and they did something and marked it Fixed, that means the person who comes across the same behavior later should go and report it again (assuming your never-reopen world). | 22:05 |
| lifeless | thats certainly one way to guide users. | 22:05 |
| mpt | If the developers thought the behavior should not be changed, and they marked it Declined, that means the person who comes across the same behavior later should just sigh and test something else. | 22:06 |
| lifeless | there are other ways to provide that guidance - faqs, docs, editing the bug subject | 22:06 |
| mpt | Yes, but those other ways uniformly involve more clicks and/or keypresses. :-) | 22:07 |
| lifeless | mpt: I'm basically just ruminating on how minimal we can be without negative side effects. | 22:07 |
| mpt | sure | 22:07 |
| lifeless | mpt: I will note that there are folk that want to require comments on closing of bugs; e.g. folk see *value* in human commentary on bugs. | 22:07 |
| mpt | and I'm rummaging for babies in this bathwater | 22:07 |
| mpt | lifeless, yes, I commented on that too a couple of days ago, with data from bugzilla.mozilla.org | 22:08 |
| lifeless | yah, I saw that go by | 22:08 |
| lifeless | assertion: the only reports where number of clicks is a dominating component of the effort involved is declined bugs | 22:09 |
| lifeless | actioned bugs, assuming automated stuff like Ubuntu has, have most of the effort happen in the code change. | 22:09 |
| mpt | I have a counterexample for that assertion | 22:09 |
| lifeless | mpt: cool! | 22:10 |
| mpt | Every so often I will see bugmail from seb128 that looks something like this: | 22:10 |
| lifeless | mpt: what is it? | 22:10 |
| mpt | Importance: Undecided -> Wishlist | 22:10 |
| mpt | Status: New -> Confirmed | 22:10 |
| mpt | *** This bug has been marked as a duplicate of XYZ *** | 22:10 |
| mpt | which makes no sense, until I realized he was using a greasemonkey script to make marking duplicates faster | 22:11 |
| mpt | The problem is that if the duplicate was mistaken, and someone just reopens the bug report, it's at Confirmed and Wishlist when it hasn't actually been seriously triaged. | 22:12 |
| lifeless | so, why is he marking it wishlist confirmed at all ? | 22:13 |
| mpt | I don't know. :-) | 22:13 |
| mpt | (Actually it might be Wishlist Invalid ... I'd need to search bugmail to be sure) | 22:14 |
| lifeless | so, ongoing food for thought | 22:14 |
| lifeless | Duplicates shouldn't be open or closed | 22:17 |
| lifeless | they are indeterminate | 22:17 |
| mpt | yes | 22:17 |
| mpt | hence, greyed-out status table | 22:17 |
| lifeless | mpt: have you seen my ruminations about moving to a 'symptoms' and 'fixes' model, rather than the simple 'bugs' we have today? | 22:18 |
| mpt | (which was a tradeoff between being completely indeterminate, and showing enough info that you could tell whether it would save time to reverse the duplicate direction) | 22:18 |
| mpt | lifeless, I have not ... That sounds like a bit like the very early days when there were separate pages (and numbers!) for bugs and tasks. | 22:19 |
| lifeless | mmm, haven't sketched at that level | 22:19 |
| lifeless | this comes out of the 'bug reports with imperatives are not bug reports' concept | 22:20 |
| mpt | Hypothesis: Any bug report that has identical symptoms to another bug report is either a duplicate or incomplete. | 22:20 |
| lifeless | yes | 22:21 |
| lifeless | so the idea was to strip out all the stuff related to what changes are needed and what a fix/nonfix is from the things that users tell us about | 22:23 |
| lifeless | rather than asking for a bug title we would ask for 'what happened', and the docs could guide folk towards reporting evidence in preference to speculation / desire | 22:24 |
| mpt | As in have two fields, something like "Description of the problem" and "Possible solutions:"? | 22:24 |
| lifeless | I think they are larger than fields | 22:25 |
| lifeless | many symptoms -> many possible solutions | 22:25 |
| lifeless | common case being one symptom one solution | 22:25 |
| lifeless | the url we give users when they report something is pretty sticky, so we wouldn't want to futz with that | 22:26 |
| mpt | That's one case where there is no great distinction between Fixed and Declined: when the solution for the symptoms described is "we removed this feature". | 22:26 |
| lifeless | indeed! | 22:27 |
| lifeless | we might want to give the cluster of symptoms+possible solutions a number | 22:28 |
| lifeless | we might want to let possible solutions apply to multiple disjoint symptoms | 22:28 |
| mpt | When I redesign a feature, I try to come up with solutions to as many of the bug reports about that feature as I can. So it's fairly common that a single code change will resolve multiple bugs -- fixing some, deciding not to fix others. | 22:28 |
| mpt | (See also my propensity for saying "(See also...)" in bug reports, or "(It may save time to fix bug XYZ at the same time as this bug)", or "(It may save time to design the fix for bug XYZ at the same time as this bug)".) | 22:30 |
| lifeless | indeed | 22:31 |
| lifeless | consider symptoms A,B,C and possible solutions X,Y | 22:31 |
| lifeless | X may fix A,B, Y may fix B,C | 22:31 |
| lifeless | and X and Y may be incompatible | 22:31 |
| mpt | yep | 22:31 |
| mpt | (though I'm skeptical because I can't think of a real example of that, and I'd expect to be able to) | 22:32 |
| lifeless | flip flop bugs | 22:32 |
| lifeless | like the one with 'contact this team' | 22:32 |
| mpt | I'm not familiar with that one | 22:33 |
| mpt | Is it that some people expect "Contact this team" to send mail to every member, and others think that's a terrible idea? | 22:33 |
| lifeless | they get very very close to this - if contact this team obeys the team contact address, we can't tell if everyone is contacted. If it does not obey the team contact address and instead mails each person, the list is bypassed and everyone has to respond or not separately. | 22:34 |
| mpt | That seems like a false dilemma, but anyway, it's just an example | 22:35 |
| lifeless | right | 22:35 |
| mpt | If Launchpad did not track branches at all, I'd be more interested in this idea of distinguishing symptoms and solutions | 22:37 |
| mpt | but so far, it seems a bit bureacratic | 22:38 |
| lifeless | the LP project itself gets a lot of imperative bugs | 22:38 |
| mpt | "This is branch X representing solution Y that fixes bug Z" | 22:38 |
| lifeless | part of the issue is the definition of 'bug' | 22:39 |
| lifeless | is it 'something that needs a code change' or is it 'the abstract thing that is wrong' | 22:39 |
| lifeless | (consider a bad coding pattern - like using sprintf - is each occurence a separate bug, is the use in each discrete project a separate bug, or is the thing itself a single bug?) | 22:40 |
| mpt | A theoretically perfect design can lead you to a system that's just too much bother to use in practice | 22:41 |
| lifeless | hell yes :) thats happened to a lot of LP | 22:41 |
| lifeless | wgrant holds the opinion that multi-pillar (product/distros etc) bugs are an example of this | 22:42 |
| mpt | Perhaps a real-life example of what you're talking about -- certainly a real-life example of what wgrant is talking about -- is Python transitions | 22:42 |
| mpt | which need to be done in dozens of packages near-simultaneously | 22:43 |
| mpt | but I can't tell which you would classify it as, "something that needs a code change" or "the abstract thing that is wrong" | 22:43 |
| mpt | They used to be done in a single bug report, but then the maintainer of package A was being spammed by status changes for packages B, C, D, E, F ... Z | 22:44 |
| lifeless | does Ubuntu file one bug saying 'transition to 2.8' | 22:44 |
| lifeless | or does it use one bug per package | 22:44 |
| lifeless | exactly | 22:44 |
| lifeless | if you look at it from a symptoms perspective | 22:44 |
| lifeless | each package that doesn't work is a separate symptom | 22:44 |
| mpt | yes | 22:44 |
| lifeless | and each solution (change package X) fixes at most one symptom (but may be a pre-requisite for fixing others due to dependencies) | 22:45 |
| lifeless | [note the handwave in the middle there] | 22:45 |
| mpt | There are Ubuntu Software Center bug reports describing problems that need work on the client and on the server | 22:46 |
| lifeless | if one wanted to, the rdepends could be used to mass create such symptoms + proposed fixes + link them all together. So you could then trivially see what work needs to be done to get say bzrlib working in 3.0 | 22:46 |
| lifeless | so, I don't have a full and clear view on what to do with all this yet | 22:47 |
| mpt | They're tracked together, because the discoordination of tracking them separately would be greater than the noise from tracking them together. | 22:47 |
| mpt | ("together" = as a single bug report) | 22:47 |
| lifeless | but, I do think that LP as it stands is driving noise in the system | 22:47 |
| lifeless | mpt: with bug dependencies you may find that gets better (we'll show dependent bug task status in a table at the top, so you can see at a glance where things are at) | 22:48 |
| mpt | I do think it's an architectural problem that you can't change multiple packages in a single branch. For example, update ubuntu-docs to reflect the change you're making to the UI of something. Or, move a checkbox from jockey to gnome-control-center. | 22:49 |
| lifeless | do you mean single branch, or single landing ? | 22:49 |
| mpt | single branch | 22:50 |
| mpt | with a single log | 22:50 |
| mpt | (I realize that would be near-impossible) | 22:50 |
| lifeless | well, bsd does it | 22:50 |
| lifeless | its definitely doable | 22:50 |
| mpt | I didn't know that | 22:50 |
| lifeless | doesn't mean its a good idea ;) | 22:50 |
| mpt | Do they have all packages in one repository? | 22:51 |
| lifeless | the bsd core system - not ports - is all in one big source tree, for all the BSDs I know of. | 22:51 |
| mpt | heh | 22:51 |
| lifeless | the ports system has all the metadata for all the packages in one tree as well. | 22:51 |
| lifeless | so you can, in a single commit, update both jockey and gnome-control-center, but the update, like debian packages, consists of either adding patches or grabbing different upstream tarballs. | 22:52 |
| lifeless | gentoo does that too | 22:52 |
| mpt | In itself, I still think dependencies are a waste of time ... they'd be worth it only as the cost of abolishing blueprints | 22:52 |
| lifeless | mpt: funny you should mention that | 22:54 |
| lifeless | mpt: I think dependencies are very useful myself, for complex multi-step changes. | 22:54 |
| lifeless | mpt: but also the blueprints thing | 22:54 |
| mpt | When I saw the announcement of the work items work in LP I did a little head-desking | 22:55 |
| mpt | If a software engineer who had never heard of Launchpad went to their boss and said, "You know, I think we should have two work tracking systems. One for defects, and another for work in general, whether that's fixing defects or something else. In the tracker for work in general, each piece of work should be a line of text, starting with the ID of the person who should do it in square brackets. And then we should have a third system, that screen-scrapes th | 23:01 |
| mpt | e second one, and makes burndown graphs" ... I'd hope they would be fired on the spot. | 23:01 |
| wgrant | mpt: I feel that multitask bugs are the source of a lot that is wrong with LP | 23:02 |
| wgrant | s/multitask/multipillar/, at least | 23:03 |
| lifeless | mpt: I agree | 23:03 |
| wgrant | And I don't like workitems one bit :) | 23:03 |
| wgrant | I was somewhat disappointed that lifeless didn't veto them. | 23:03 |
| lifeless | mpt: linaro however wanted to automate what has grown organically; we need to fix the underlying facilities before we can consolidate | 23:03 |
| lifeless | wgrant: the time to veto them was 4 years ago | 23:03 |
| lifeless | wgrant: when folk started inventing task tracking inside blueprints; the modelling of them in LP is neither here nor there | 23:04 |
| wgrant | lifeless: You've retroactively vetoed a lot of stuff like that :) | 23:04 |
| lifeless | wgrant: always with an eye on the impact and how folk will acclimatise | 23:04 |
| lifeless | bah, spelling | 23:04 |
| mpt | I think the way to get rid of something that has inertial stupidity is to make its replacement more attractive. | 23:04 |
| lifeless | right | 23:04 |
| lifeless | win by competing | 23:05 |
| mpt | For example, integrate burndown charts in LP ... for bugs but not for blueprints. | 23:05 |
| mpt | (You want something to show on the burndown chart? Nominate it for the series. That's what series are for.) | 23:06 |
| lifeless | mpt: well, I want to remove non-series bugs, simplifying a bunch of model and code in LP and making it easier to reason about | 23:06 |
| mpt | That works too (though I'm dubious about it in general). | 23:07 |
| lifeless | there's also the tension between planning milestones and recording milestones to sort out; I think it would be nice to have just one way to plan things | 23:07 |
| lifeless | (for deadline planning that is) | 23:07 |
| mpt | Is "planning" there an adjective or a verb? :-) | 23:08 |
| lifeless | I don't know :) | 23:08 |
| mpt | wgrant, what are some examples of the wrongness caused by multi-task bugs? | 23:12 |
| wgrant | I hope that the stakeholders who shall remain anonymous will be convinced that multitask bugs can go away once bug linking exists :) | 23:12 |
| mpt | apart from bug 1 | 23:12 |
| _mup_ | Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice Productivity Suite:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <metacity:In Prog | 23:12 |
| wgrant | mpt: Every notable piece of data in Launchpad is owned by a project (except for a few things that are owned by people or teams). | 23:12 |
| wgrant | mpt: Except bugs. | 23:12 |
| wgrant | mpt: Which aren't owned by a person. | 23:12 |
| wgrant | mpt: And aren't owned by a project. | 23:12 |
| wgrant | They are cooperatively owned by projects. | 23:12 |
| mpt | wgrant, that's theory. Give me practice. | 23:12 |
| wgrant | mpt: Who controls access to a cross-pillar bug? | 23:13 |
| mpt | ok, that's a good one | 23:13 |
| wgrant | Nobody owns the data. | 23:13 |
| wgrant | The project owner can't control access to their project's private bugs. | 23:13 |
| mpt | Another one: There are multiple URLs to pages that are exactly the same except for the highlighting of a table row. | 23:13 |
| wgrant | And there is the whole notifications mess. | 23:13 |
| wgrant | mpt: Well | 23:13 |
| wgrant | mpt: And some of the other links are silently context-sensitive. | 23:14 |
| wgrant | But nobody realises this. | 23:14 |
| wgrant | (eg. Target to series) | 23:14 |
| mpt | yes | 23:14 |
| wgrant | mpt: It also causes problems with the person pickers. | 23:14 |
| wgrant | Because if I want to search for say someone to subscribe or a branch to link, it pretty much has to search all of Launchpad.; | 23:14 |
| wgrant | (or prioritise people from all the related projects, but that's getting silly) | 23:14 |
| wgrant | The notifications thing is part of why we have bug muting. | 23:15 |
| wgrant | Ubuntu tried multi-task bugs for a couple of transitions. | 23:15 |
| wgrant | With maybe 250 packages. | 23:15 |
| wgrant | It doesn't result in usable UI, and the bugs just get huge and very noisy. | 23:16 |
| mpt | Transitions were never what multi-task bugs were intended for anyway. | 23:16 |
| wgrant | Even now you can't mute notifications from just some of the tasks. | 23:16 |
| mpt | If people would have inevitably made that mistake, that's a good example, otherwise it's just misuse. | 23:16 |
| wgrant | Even Launchpad abuses multi-task bugs in privileged ways that wouldn't be acceptable for other projects to do. | 23:16 |
| wgrant | eg. bug in Loggerhead -> have a Loggerhead task, and a Launchpad task to track its deployment on Launchpad. | 23:16 |
| wgrant | We consider that acceptable because we own both projects. | 23:17 |
| wgrant | And we get noise from both anyway. | 23:17 |
| wgrant | But that's a privileged position. | 23:17 |
| wgrant | What if SourceForge added tasks on all Loggerhead bugs? | 23:17 |
| mpt | Unity abuses multi-task bugs in a similar way ... I'm almost tempted to agree with you for that reason alone | 23:17 |
| wgrant | Or, say, a distro named Baltix on all of Ubuntu's bugs. | 23:17 |
| wgrant | It forces the upstream to know about the downstream. | 23:17 |
| wgrant | And be notified about the downstream. | 23:17 |
| lifeless | mpt: you cannot misuse someting that doesn't exist; the feature existing invites its [mis-]use. | 23:17 |
| wgrant | When really they don't give a shit. | 23:17 |
| wgrant | Except that they want the bloody noise to stop :) | 23:18 |
| mpt | lifeless, you could say the same about Launchpad as a whole! I'm talking about misuse vs. productive use | 23:19 |
| lifeless | mpt: I was addressing your 'inevitably misuse it' thing - we invite that by how we design and present the feature | 23:20 |
| mpt | lifeless, right, I meant "if they would have made that mistake even if we presented it in the clearest possible way" | 23:21 |
| mpt | wgrant, there is a deep irony here. Launchpad was intended to become what Github has become, i.e. the center of the open-source universe. If it had, multi-task bugs would have been more useful. But it didn't at least in small part because it was too complicated ... for example having multi-task bugs. :-) | 23:22 |
| lifeless | mpt: one of the key insights I had on bugs a while back was that who gets notified maps to who will participate in the conversation | 23:22 |
| wgrant | mpt: Oh yes | 23:23 |
| lifeless | mpt: and it follows from that that the *size* of the conversation is deeply connected to how you partition data | 23:23 |
| wgrant | mpt: The situations that multi-task bugs are good in are probably better solved in other ways. There are questions around how we share the conversation, but the current no-opt-out conversation sharing isn't working either. | 23:24 |
| lifeless | mpt: both for private data (you can't combine multiple private-data bugs even if they have the same symptoms) and for related-things (just because something is related doesn't mean you want a large conversation) | 23:24 |
| mpt | lifeless, I have the sneaking suspicion that the ideal bug tracker wouldn't send e-mail at all. I don't know what it would look like, though. | 23:25 |
| mpt | You'd go ... somewhere and see all the issues that might benefit from your input. | 23:25 |
| lifeless | mpt: heh | 23:25 |
| mpt | and somewhere to see all the issues that were blocked on you. | 23:25 |
| lifeless | I'm not sure there is a right answer | 23:25 |
| mpt | (Maybe the same place for both.) | 23:26 |
| lifeless | I think those are necessary features for a good bug tracker | 23:26 |
| lifeless | Who wants notifications and when is more complex ;) | 23:27 |
| mpt | If the purpose of a bug tracker is to help developers make better use of their time, then the ultimate is "Here is an ordered list of things on which your time would be best used" | 23:28 |
| lifeless | I want one that covers multiple forges | 23:28 |
| lifeless | :) | 23:28 |
| mpt | At the risk of using a buzzword, that could be a game-changer | 23:29 |
| mpt | at least for people who are at least partly volunteers | 23:29 |
| lifeless | LP's federation facilities could do it, if we finished it | 23:29 |
| wgrant | I thought LP was meant to do that. | 23:30 |
| wgrant | Having global bug numbers basically prevents it. | 23:30 |
| wgrant | But I thought that was a vague LPish goal originally. | 23:30 |
| mpt | get out of the competition between trackers, and into "here's all the things I can do, everywhere" | 23:30 |
| huwshimi | mpt: We've been talking about that (well at least I have). We currently use email to solve the whole problem of notifications instead of managing them in-house (and make users do all their personal prioritising outside LP). | 23:32 |
| mpt | huwshimi, and inboxes suck as task lists :-) | 23:32 |
| huwshimi | mpt: Exactly! | 23:32 |
| huwshimi | mpt: One of our planned goals was to create personal dashboards | 23:34 |
| huwshimi | mpt: But, we don't have the time for that now :) | 23:34 |
| lifeless | I have a fair chunk of a notification system overhaul done. | 23:34 |
| lifeless | but its not a top priority | 23:34 |
| wgrant | Yes, but you're the only person who will be able to touch it for at least a year and probably ever Z:) | 23:34 |
| mpt | Possibly the ideal bug tracker would still send notifications, but only by SMS, because that's how urgent they'd be | 23:35 |
| huwshimi | haha | 23:35 |
| mpt | huwshimi, there are plenty of ways Launchpad can be improved merely by removing stuff | 23:35 |
| mpt | Ooh, I should show you my user style sheet | 23:35 |
| wgrant | Um | 23:36 |
| wgrant | The former LP UI designer uses a user stylesheet rather than filing bugs to get it fixed for everyone? :) | 23:36 |
| lifeless | mpt: I'm glad you're getting somet time to think about LP again. | 23:39 |
| wallyworld_ | wgrant: why did you revert my audit sharing stuff? the owner of a project has a right to see who can access their project and the implementation was as agreed | 23:39 |
| wgrant | wallyworld_: It wasn't restricted to the owner. | 23:40 |
| wgrant | And that wasn't agreed with everyone who uses private teams. | 23:40 |
| wallyworld_ | it was agreed with us on the call | 23:40 |
| wgrant | wallyworld_: eg. as an unprivileged user I was able to find a bug with Canonical subscribed, retarget it to my project, make it private, and read all of Canonical's memberships. | 23:40 |
| wgrant | => inappropriate | 23:40 |
| wallyworld_ | the audit sharing view has launchpad.Edit permissions against it | 23:41 |
| wgrant | Sure | 23:41 |
| wgrant | But bugs can be retargeted. | 23:41 |
| wgrant | So I can create a project, find an interesting bug, move it to my project, and have root :) | 23:41 |
| wallyworld_ | so that's not the fault of the audit sharing implementation | 23:41 |
| wgrant | It's still a complete hole. | 23:42 |
| wgrant | (and yes, it is) | 23:42 |
| wgrant | Well | 23:42 |
| wallyworld_ | i implemented what we agreed to | 23:42 |
| wgrant | It's a fault of the design. | 23:42 |
| wgrant | And I disagreed with the design, and on the grounds that it completely violates the team security policy I will not let it persist in the tree until it is fixed. | 23:42 |
| wallyworld_ | that's not your call | 23:42 |
| wgrant | Nope. | 23:42 |
| wgrant | But I'll do it anyway. | 23:42 |
| lifeless | the hole wgrant just described is one jane would be extremely unhappy with. | 23:43 |
| wgrant | Precisely. | 23:43 |
| wgrant | your team is private. loljk. | 23:43 |
| wallyworld_ | sure, but some collaboration would have been nice and curteous | 23:43 |
| lifeless | she has put a mandate out there that the membership of ~canonical must-not-be-disclosed | 23:43 |
| wgrant | wallyworld_: I tried to ping you. | 23:43 |
| wgrant | wallyworld_: But you weren't around. | 23:43 |
| wgrant | And I didn't want to comment in the bug while it was live on production data. | 23:43 |
| wallyworld_ | ok | 23:43 |
| lifeless | wgrant: can we tell if anyone abused it while it was on qastaging ? | 23:44 |
| wgrant | lifeless: We can make reasonable guesses from logs. Let's see if I can find them. | 23:44 |
| lifeless | wallyworld_: wgrant: could you please check; if it looks like a nontrivial thing to determine, please open an incident report. | 23:44 |
| wgrant | Of course this just *has* to be across a DST shift, doesn't it... | 23:46 |
| mpt | huwshimi: http://i.imgur.com/Vr465.png | 23:47 |
| mpt | Spot the differences | 23:47 |
| poolie | hi all | 23:48 |
| wgrant | mpt: Aw | 23:48 |
| poolie | hi mpt, thanks for your cites on my Opinion bug | 23:48 |
| wgrant | mpt: You didn't fix the subscription portlet as much as I expected :( | 23:48 |
| mpt | wgrant, there's only so much I can do in CSS alone ... I just hid the first line of text | 23:49 |
| wgrant | Ah :( | 23:50 |
| mpt | poolie, you're welcome | 23:50 |
| wallyworld_ | wgrant: do you know why there's a gap in the log file dates on asuka? | 23:52 |
| wgrant | wallyworld_: Of about 2 months? I hope it's just a partial rsync. I requested a full sync a few minutes ago. | 23:53 |
| lifeless | wgrant: hows carob's disk space looking | 23:53 |
| wgrant | Otherwise logrotate is terribly misconfigured and someone will be digging on aboa :) | 23:53 |
| wgrant | lifeless: over 9000 | 23:53 |
| wgrant | Or 128GB, whichever. | 23:53 |
| lifeless | wgrant: spm disabled full syncs till the oops were cleared | 23:53 |
| wallyworld_ | wgrant: it seems to be a few days from 26/3 till 1/4 | 23:53 |
| wgrant | lifeless: I know. | 23:53 |
| lifeless | wgrant: kk | 23:53 |
| wgrant | lifeless: We have another few tens of gigabytes of oopses to delete in the next day or two, I believe. | 23:54 |
| wgrant | But might switch it on anyway since spm is off. :) | 23:54 |
| * wgrant drowns in librarian logs. | 23:54 | |
| mpt | wgrant, I'm just experimenting at the moment ... bug reports come later | 23:54 |
| wgrant | mpt: I'm not sure that's ideal. Last time someone proposed a change to the subscriptions portlet it became 10x larger and unintelligible :) | 23:55 |
| wgrant | The next change will likely cause it to fill the entire sidebar. | 23:55 |
| wgrant | With meaningless text :) | 23:55 |
| wgrant | wallyworld_: Sync done | 23:56 |
| mpt | "You are not directly subscribed to the notifications of the mail about the changes to the notifications, but you might be subscribed to the notifications of the notifications." | 23:56 |
| wallyworld_ | ok | 23:56 |
| wgrant | launchpad.log.1 is now from 2012-01-23 to 2012-03-31 | 23:56 |
| wgrant | Which is I think a complete record. | 23:56 |
| wgrant | The code was deployed around 2012-03-31T09:00 | 23:56 |
| wgrant | It was all me and wallyworld. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
