=== ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #launchpad === Topic for #launchpad: Launchpad https://launchpad.net/ | Next developer meeting: Thu 21 June 2007, 1400UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Launchpad help: https://help.launchpad.net | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by mpt at Thu Jun 14 16:04:24 2007 === #launchpad [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === merriam [n=merriam@85-211-180-104.dyn.gotadsl.co.uk] has joined #launchpad === raphink [i=raphink@ubuntu/member/raphink] has joined #launchpad === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #launchpad === Hobbsee_ [n=Hobbsee@ubuntu/member/hobbsee] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === kiko is now known as kiko-zzz === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #launchpad === Topic for #launchpad: Launchpad https://launchpad.net/ | Next developer meeting: Thu 21 June 2007, 1400UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Launchpad help: https://help.launchpad.net | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by mpt at Thu Jun 14 16:04:24 2007 === #launchpad [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #launchpad === stub [n=stub@ppp-58.8.15.109.revip2.asianet.co.th] has joined #launchpad === tjs [n=tjs@203.206.162.25] has left #launchpad [] === Hobbsee pokes kiko-zzz [06:05] "for example when I set a bug to needs info, I generally assign it to the reporter to make this clear" [06:05] Now that's interesting [06:05] yes, there's a problem with the bug stuff. [06:06] it totally misses the case of sponsoring. [06:07] (do we outline what "sponsoring" is in case people here aren't 100% with the terminology?) [06:07] i'm emailing the list now [06:07] well, -devel-discuss [06:07] Let me guess: casual contributor A makes a fix, but it's actually uploaded by Developer B? [06:07] was planning to point to that while talking [06:07] mpt: that's the one. [06:07] mpt: pretty much, and it's very common === mpt cries [06:07] contributor A should be able to assign to himself, and be able to set the status. [06:08] yes === owh [n=onno@59.154.24.148] has joined #launchpad === RAOF [n=Chris_@matht464.maths.unsw.edu.au] has joined #launchpad === StevenK [n=stevenk@14.5.233.220.exetel.com.au] has joined #launchpad [06:10] mpt: why in particular crying? [06:11] because I suspected this sort of problem might happen [06:11] though to be honest, I hadn't thought about mentoring, I was more concerned with undo [06:12] e.g. non-"developer" accidentally moves a bug from Todo to Triaged, and can't change it back [06:12] s/mentoring/sponsoring/ [06:12] Hobbsee, LaserJock already described the sponsoring issue [06:13] mpt: ahh [06:14] mpt: i'd suggest, to use someone else's suggestion here, to only let them change the status to a developer status if they're assigning it to themself. [06:14] because that says "i'm working on this, no one else needs to touch it" [06:14] that would fix part of it [06:14] what wouldnt it fix? === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #launchpad [06:17] mpt: ^ [06:17] it doenst fix the accidently sending it back, true [06:18] mpt: and this really needed to be a part of -devel-discuss or something, btw - the ubuntu develoeprs are going to have opinions on this sort of stuff [06:18] which is why a few of us were found, even at UDS. [06:18] What's wrong with allowing the asignee to set the status to whatever they want? [06:20] [06:20] :) === ScottK [n=ScottK@ubuntu/member/scottk] has joined #launchpad [06:21] Hobbsee, the part where "developer" B is discussing a bug with person A on IRC, and says "sure, report it and assign it to me" [06:22] mpt: but that never happens. [06:22] oh wait [06:22] Not everyone uses IRC, and there's no universal medium. [06:22] mpt: that happens a lot less [06:22] mpt: and could be changed to "file a bug, and give me the number, for me to assign it to myself" [06:24] Which is more work for developer B, whereas the current workflow has person A doing it all. [06:25] this is true [06:26] I suspect I'm being dense, but I'm not sure what breaks if you allow anyone to allocate a bug to themselves, then allow the person to set the status of the bug they took on. Can someone hit me with a clue-bat? [06:26] owh: that part is fine - it just doesnt solve the other case [06:27] Hobbsee: Then I don't understand the other case. Did I miss some part of the conversation? [06:27] owh: [14:21] Hobbsee, the part where "developer" B is discussing a bug with person A on IRC, and says "sure, report it and assign it to me" [06:28] Hobbsee: Yeah, I saw that, so I go to LaserJock and ask him about a bug, then he tells me to report it and assign it to him, or am I misunderstanding? [06:28] owh: correct [06:29] Hobbsee: So, how does that not work? LaserJock is now the assignee of a bug I put him into. Is that not currently the case? [06:29] owh: because you can only assign the bug to yourself if you'r enot a dev. that's the point. === owh is feeling pretty dumb, bit I'm still not understanding. [06:29] er, if you are a dev [06:29] owh, the difference being you can't set it to Todo because (in this scenario) you're not a "developer" [06:30] mpt: er - can you still assign it to someone else if you're not a develoepr? [06:30] hmm [06:30] I don't know [06:30] probably not [06:30] Hold on, one thing at a time. Can I or can I not assign a bug as a normal person to someone else? [06:30] I guess you probably can [06:30] mpt: Surely you can check the spec. [06:30] :) [06:30] This isn't covered in the spec, iirc [06:30] Oh, neat, a spec that doesn't spec out the feature :) [06:31] The BugWorkflow spec is about statuses, not about workflow [06:31] well, not about assignees [06:31] Oh. [06:31] Is there any point in doing a test? I can create a dummy bug and assign it to Hobbsee if you like. [06:32] owh: It hasn't been rolled out yet. [06:32] I would have thought it might be on edge, but apparently not. [06:32] owh, you can do that on staging.launchpad.net [06:32] But are we saying that this behaviour has changed? [06:32] mpt: Right now? [06:32] owh, afaik [06:33] mpt: Does the person I assign it to have to be a member of any group, or is it limited to particular groups, or perhaps "not" to a particular group? === Starting logfile irclogs/launchpad.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #launchpad === Topic for #launchpad: Launchpad https://launchpad.net/ | Next developer meeting: Thu 21 June 2007, 1400UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Launchpad help: https://help.launchpad.net | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by mpt at Thu Jun 14 16:04:24 2007 === owh is logged in and clicking away. [06:35] I can confirm that the spec doesn't mention assigning/reassigning bugs [06:35] owh: or this behaviour will change in a day or two [06:35] I don't know if it's live yet [06:35] mpt: is there any problem with making this particular spec public? even if you sanitize it first? [06:35] ajmitch: Yeah, that's what we really don't know. [06:35] Fujitsu: Hmm, I spoke too soon. My timeout just came too :) [06:36] Hobbsee, I'll discuss that with BjornT when he's up [06:36] Hm, apparently just Malone doesn't work on staging. Convenient. [06:36] worksforme [06:37] As ajmitch points out, this won't actually help us though will it? [06:38] I think staging code is meant to be in sync with production, so probably not. [06:38] Fujitsu: So, tell me again the point of staging the same version as the live version? [06:39] Edge is meant to be more cutting-edge. Staging is just there as a testing ground [06:40] Fujitsu: But if it's a testing ground, what are you testing. If it's the same version as the live version, that makes no sense to me. [06:41] Sorry, for users to play around with on a non-production database. [06:41] owh, what do you mean by "staging the same version as the live version"? [06:41] staging.launchpad.net is, at the moment, newer code than launchpad.net [06:41] that's why staging.launchpad.net has the new bug statuses, and launchpad.net does not [06:42] Ahh, so it does? I can't see them, it just times out. [06:42] mpt: It also times out for me, if you need a specific oops: OOPS-536S13 [06:42] https://devpad.canonical.com/~jamesh/oops.cgi/536S13 [06:42] Cool [06:42] Hmm, it needs a pwd :) [06:42] Is there any log or anything showing how the various sub-LPs compare code version-wise? [06:43] It seems that just the bug listings timeout, while specific bugs work. [06:45] Fujitsu, yes, the page footer tells you exactly what revision is running [06:46] so launchpad.net is running r4287, while staging.launchpad.net is running r4419 [06:46] mpt: I recall I was told a couple of weeks back that they weren't comparable, as they're from different branches. [06:46] really? That might be true, but I don't understand why it would be [06:47] Hobbsee: I've just assigned a bug to you (under staging), so we'll see what it does. [06:47] I suspect that's the revision of the staging/production/edge bzr branch, which are merged from rocketfuel regularly. [06:47] Hobbsee: Yup, you are now the Assignee. [06:47] https://bugs.staging.launchpad.net/ubuntu/+source/gphpedit/+bug/73310 [06:47] Launchpad bug 73310 in gphpedit "Selected text colour does not follow theme" [Low,In progress] - Assigned to Onno Benschop (onno-itmaze) [06:47] This is a STAGING bug, not a real one! [06:48] yep [06:48] ubotu, you silly wabbit === Fujitsu assigned himself to a bug on staging and can't touch any other statuses. [06:49] mpt: Once the production branch gets cherry picks, the numbers are no longer comparable. edge and beta revnos are never comparable (as they get at most one commit per day but launchpad/devel gets several) === cprov is now known as cprov-ZzZ [06:50] Hobbsee: I'm now taking it back to see if I can change the status. [06:50] stub: Ah, that's what I thought. [06:51] Fujitsu: I can change the Status, but I cannot change the Importance. === neversfelde [n=neversfe@nrbg-4db445bf.pool.einsundeins.de] has joined #launchpad [06:51] ok, thanks stub [06:51] mpt: Hey, this is still the old levels. === owh is confused. [06:51] owh, I was just there ten minutes ago seeing the new ones [06:51] mpt: I thought that the staging version was the one that is going to be rolled out. [06:51] owh: Mortals can't change the status to wontfix, triaged, or todo. [06:51] mpt: erm...what happens in the case that a bug triager, not a ~ubuntu-developer, goes through, and finds the bug is already fixed upstream? They cant mark a bug as fix released, i believe. [06:52] Hobbsee: It seems they can. [06:52] Fujitsu: if the statuses go thru as intended, though [06:52] Hobbsee, arguably Fix Released isn't the appropriate resolution for that case anyway [06:52] The only statuses that aren't accessible to the unprivileged are wontfix, triaged and todo. [06:52] I'm a nobody, that is, I'm not a member of any groups. I've just set the status to "Fix Released". [06:52] Won't Fix is [06:53] mpt: "upstream has released the fix for this" - it is the appropriate resolution [06:53] mpt: No, Fix Released is. [06:53] Hobbsee, it's not going to be fixed specifically in Ubuntu, Ubuntu's just going to pick up the fix when it picks up the new release [06:53] mpt: the new release has often already occured. [06:53] Well, I think this is presuming the release is already here. [06:53] Wont Fix might work, but Fix Released is probably better. [06:54] are you saying that now, the ubuntu bug should have wontfix, and the upstream bugs should be linked, etc, etc, etc [06:54] On this page, I only see the current status options: https://bugs.staging.launchpad.net/ubuntu/+source/gphpedit/+bug/73310 [06:54] Launchpad bug 73310 in gphpedit "Selected text colour does not follow theme" [Low,In progress] - Assigned to Onno Benschop (onno-itmaze) [06:54] mpt: ^ [06:54] Hobbsee, that's how I always imagined it working (but probably no-one ever told the Ubuntu developers) [06:54] :) [06:55] mpt: that's a shitload of extra work, for very little gain === owh agrees. [06:55] mpt: and i'm not even going to go into the latter issue. yet. [06:56] Hobbsee, what's the difference in work between moving a bug to Fix Released, and moving it to Won't Fix? [06:57] mpt: for when someone looks up an old bug, and goes "oh, okay, this has been fixed in a later version", rather than "oh, okay, so obviously they dont care, and wont fix it" === owh nods. [06:57] i can tell you now - the upstream bugs wont be linked a lot of the time, because it's a lot of extra work === Fujitsu really doesn't want to register a bugtracker and project just to set a bug status properly. [06:57] mpt: "wont fix" really means "yes, we know it's a bug, but we're not going to fix it" [06:57] mpt: whereas "fix released" means "it's a bug, it's been fixed, and it's in the archives" [06:58] there's a big difference there [06:58] although, if WONTFIX isnt shown on the default search, it's not a major issue. [06:58] wontfix is a semi-closed state, or should be at least. [06:58] "won't fix" also is an opportunity for someone else to come along and pick it up, where "fix released" is "This one's done, next." [06:59] Hobbsee, I understand what Ubuntu developers have been taking the statuses to mean [06:59] What I don't understand is your "extra work" comment [06:59] that's true - "wontfix" is an invitation for someone to go "but i'd really like to see this fixed, i'm willing to do the work to fix it if no one else is" [06:59] owh, whoa, how did you do that [06:59] oh wait [06:59] mpt: Do what? [06:59] That *is* the new statuses [06:59] but we can see only a subset of them [07:00] Notice how they have new names [07:00] mpt: the having to look up the upstream bug, link it, wait for the status of the upstream bug to update [07:00] Hobbsee, why would you have to do that any more than you do now? [07:01] mpt: because what happens now, for a lot of the time, at least for kde bugs, is that people go through, adn try to check if it still exists. often, it'll have been fixed in a later vesrion, so they'll mark it as fix released, instead of rejected [07:01] mpt: As I understand Hobbsee's point, if we use Won't Fix as you suggest, then we need to document why. If the fix is released, it doesn't matter. [07:02] hrmm [07:02] Hobbsee: Is that what you mean, or should I not put words in your mouth? [07:03] as in, "hey, whaddya mean it won't be fixed"? [07:03] owh: kidna. [07:03] mpt: Yes. [07:03] mpt: yeah. [07:03] This is why I wanted to call the status "Won't Fix *Here*" [07:03] Hobbsee: Does it have prickles this kidna of yours? [07:03] (back when I still wanted it at all) [07:04] owh: Heheh. [07:04] "Won't Fix" will really confuse some users [07:04] but I guess even that wouldn't have resolved all the confusion [07:04] mpt: From my perspective, fix released means that the fix exists, it will come when it comes. [07:04] I still think SEP is better :P [07:04] owh: No, that is *not* what Fix Released means. [07:04] i think wontfix should be only used for things of "we dont want to fix this for whatever reason, but acknowledge that it's a bug" [07:04] Fujitsu: ROTFL, I chocked on that. Bad. Coughing and spluttering. === Hobbsee ROFL's at Fujitsu [07:05] SEP rocks.k [07:05] Well, *cough*, Fix Released wasn't intended to be used the way Ubuntu developers use it either === owh agrees. [07:05] mpt: yeah, true that. we've had arguments on that already :P [07:05] Version tracking would make that practical. [07:05] So, really what we're up against is that there are multiple understandings of what the status flag means. Perhaps this is the real problem. [07:05] I regret to say I was a bit of an architecture astronaut back then [07:05] (as well as generally being useful) [07:06] overestimating the status-flipping people would be interested in doing [07:06] Gah, about to be dragged out by my hair, apparently. [07:06] but I'm cured now [07:06] of course... [07:06] it was beaten out of you? [07:07] mpt: Wouldn't it be fair to say that the status gets flipped when people think something's changed, that is more information became available? [07:07] the "i can change the status of any bug assigned to me" would solve the "being able to mark as fix released" problem. [07:07] owh, I don't know what you mean, unless you're referring to the Incomplete status in particular [07:08] mpt: No, you said "overestimating the status-flipping people would be interested in doing", that's what I was responding to. [07:08] ajmitch, I beat it out of myself :-) Nowadays I think there should be five bug statuses [07:08] mpt: [07:08] Another workflow example that requires this is a member of bugsquad [07:08] who discovers that a bug in a package pulled directly from Debian has [07:08] been fixed in a newer version, and needs to set the status to "Fix [07:08] Released" with a comment indicating the version in which it is fixed. [07:08] also occurs [07:09] ah, versions [07:09] owh, sorry, I still don't understand [07:11] mpt: Perhaps I don't understand what you mean when you say "overestimated the status flipping", How else do you expect people to flip the status? Are there processes that you envisaged that are not being used or that we don't know about? [07:13] owh, I mean, I overestimated the time which people would be interested in spending on changing the status of bug reports [07:13] for example [07:13] ROTFL [07:13] mpt: Sorry. [07:13] mpt: They don't want to spend any time at all:) [07:13] the original idea was that when a bug was fixed in the development version (e.g. Gutsy) it would be marked Fix Committed [07:13] Sure [07:14] then when Gutsy was released as 7.10, all those Fix Committed bugs would be changed to Fix Released [07:14] but that's infeasible [07:14] that's just painful [07:14] Yeah, my understanding of Fix Committed is that it's been sent to the queue. [07:14] as we tend to use committed for other stuff [07:14] largely because we don't have mass status changing, but only largely, not completely [07:15] because in that case, there's no easy to tell difference between "fixed in bzr, or upstream somewhere, and fixed in the archive" [07:15] partly because people just wouldn't be bothered [07:15] mpt: Mass status changing is a ****VERY**** bad idea IMHO. [07:15] maybe [07:15] Mass other-stuff changing is needed [07:15] er, we still have confirmed in there? [07:15] (e.g. mass milestone targeting) === Hobbsee cant actually see the use case for a separate confirmed, when there's a triaged [07:16] Hobbsee: Yup, I see that too. [07:16] At the moment I understood it to mean "Me too" [07:16] "Triaged - may only be set by a bug contact" [07:16] s/it/Confirmed/ [07:16] (that's from the spec) [07:17] so anyone can mark as Confirmed, only bug contacts can mark as Triaged [07:17] mpt: How is a bug contact defined? [07:17] owh: people subscribed to the bugs of a package [07:17] owh: can be a person or team [07:18] then again... [07:18] So, the sequence is New -> Need Info -> Confirmed -> Triaged -> In Progress -> Fixed. [07:18] by assigning to yourself, you're saying that you are taking responsiblity of the bug. [07:19] Yeah, that's what I understood it to be. [07:19] in which case, you should be able to set whatever you like. [07:19] and it's yoru fault if you get it wrong. === owh agrees. [07:19] Yup === owh hands all bugs over to Hobbsee [07:19] :) [07:19] which only has an inconvenient side effect of getting lots of bugmail from them. [07:20] owh: heh. i have enough, being on the kubuntu council [07:20] As a non group member, I do not expect to be able to set the Status to "Fix Released", but currently I can. [07:20] owh, you missed Todo [07:20] Hobbsee: See, you should have stayed with Gnome :) [07:20] owh: i cant stand gnome. [07:21] mpt: Yeah, between Triaged and In Progress [07:21] mpt: TODO isnt there [07:21] Hobbsee: I put up with it. [07:21] Hobbsee, it is for "developers" [07:21] mpt: Indeed, Hobbsee makes a fair point :) [07:21] mpt: which is, sorry? [07:21] mpt: I'm a developer. I download source, play with it, fix stuff. [07:21] mpt: developers != the people in ~ubuntu-dev. [07:21] mpt: That's the real problem. [07:21] mpt: developers > the people in ~ubuntu-dev. [07:22] s/>/>>>/ [07:22] huh [07:22] you're right [07:22] I don't see Todo for a bug report about Launchpad itself [07:22] that's very strange [07:22] :) [07:23] it's saying "TOO MANY STATUSES. NO MORE! [07:23] Hobbsee: What about a slider, you know between borked and fixed :) [07:23] well [07:23] haha [07:24] I'm not sure if I can really see a case where a status should be tied to a group [07:24] Infinite status. [07:24] seems to me like all status's should be available to everybody [07:24] Yup, I was just about to write that :) [07:25] do we have a reason for making only some statuses available to some poeple? [07:25] LaserJock: Is there an argument for giving "fix released" to everyone? I wouldn't feel comfortable with that flag, I'm not privileged to add stuff, just tell people about it. [07:26] LaserJock: so that the odd few people cant abuse it. === owh expects to make a fix, attach it, then tell someone. [07:26] owh: why not? [07:26] Hobbsee: so? [07:26] we let people do things all the time [07:26] LaserJock: i'm not saying it's a good one - that's jsut the reason [07:26] afaik [07:26] the whole wiki is open to anyone, why not the bug tracker [07:27] LaserJock: Well, I didn't think I should have the privilege to add a fix to the queue, so I shouldn't be able to mark it Fixed either. [07:27] as long as they can't really mess something up [07:27] owh: why? if you fixed something you should be able to mark it as such [07:27] if people are doing the work they should be able to show it [07:28] LaserJock: Sure, but how is that taken care of in terms of uploading a fix that does something evil. Or am I missing your point? [07:28] uploading is the only thing that really separates devs from non-devs [07:28] and that's soyuz, not malone ;-) [07:28] owh: I'm saying, the only difference, where bug reports are concerned, is that I can acutually upload and you can't [07:29] but you can do the work, you can do the triaging, you can do everything but upload [07:29] LaserJock: Works for me. Of course you could mark a bug as fixed when it has not been though. [07:29] sure [07:29] people make mistakes [07:29] no biggie, we learn and move on [07:30] I'm afraid if we start saying "No we don't trust you" then nobody is going to want to help out [07:30] LaserJock: So, I'm a software developer, I have a whizz bang product that's buggy as all getup. It's packaged in Ubuntu. It gets bugs lodged against it, I come along and mark them all fixed. [07:30] Hmm, I typed all that, then you came along with your comment. [07:31] I agree. I'd rather live in a society where we do trust people. [07:31] well, we get bugmail, say "hmm, we need to educate this guy a little", and you learn [07:31] I've rarely seen cases when a person continually messed stuff up [07:31] Yeah. Cool. All good. So, we give everyone all privileges, except upload. Works for me. [07:32] well, that's essentially the case as it is now === owh adds a snake in the grass. "What about Importance?" [07:32] Importance is the only thing that I'm aware of [07:32] and I don't know that many people really care about that ;-) [07:32] I don't use it [07:32] maybe some do [07:32] LaserJock: That's because you can't :) [07:32] sure I can [07:33] As a member of which team? [07:33] ubuntu-qa [07:33] Fair enough. [07:33] Well now that we've solved that... === mpt just happens to come across a Launchpad bug that some random stranger has assigned to him-/her-self [07:34] heh [07:34] yes, it happens occasionally [07:34] people were routinely abusing Importance (*every* bug I report is important) [07:34] bug 2553 [07:34] Launchpad bug 2553 in launchpad "Can't edit group wiki page details" [Medium,Confirmed] https://launchpad.net/bugs/2553 - Assigned to Jijo Baby (jijobaby) [07:34] mpt: So, can we all have all Status options, or will we have to wait for that? [07:35] mpt: Ask jijobaby for a status report :) [07:35] owh, I don't know, sorry [07:35] well, my suggestion would be to work out workflows for developers (~ubuntu-dev) and non-developers [07:35] then figure out how statuses and permissions best suit the workflow [07:36] LaserJock: Well, as someone fixing stuff, I'd like to be able to show that I'm working on it, so someone smarter than I doesn't come along, fix something I've been working on for weeks and leaves me in the dust :) [07:36] I don't mind changing workflow, but I kinda dislike doing it willy-nilly and I want to make sure non-developers are accounted for [07:37] LaserJock: I can see that I'm picking up more bugs, so marking them as ToDo would be great for my personal workflow. [07:39] mpt: oh neat. that's a changed assignee, and a spammed bug report [07:39] Hobbsee: From me? gphpedit? [07:39] owh: no, the bug mpt mentioned [07:40] Hobbsee: Sorry, I thought you were looking in your mailbox and noticing stuff from the staging server. [07:40] nah [07:40] i dont seem to have that yet, though [07:40] or else it's lost amongst all the other bugmail [07:41] Hobbsee: I don't have it either. If all works as it should, perhaps it won't generate email :) [07:42] I think a good "solution" (I don't even know the problem) is to allow assignee's and developers to change statuses freely [07:42] and allow anybody to assign themselves [07:42] Yup. [07:42] LaserJock: +1 [07:42] guess we'll need to wait for input from the powers that be, though === owh thought that LaserJock was the Master of the Universe. Perhaps the Universe is smaller than I thought :) [07:43] owh: he's a core dev, too [07:43] Hobbsee: :) [07:44] He is now. Incidentally, congratulations LaserJock :) === owh wanders off for a late lunch. === ajmitch now grovels before LaserJock [07:45] bah [07:46] thanks RAOF [07:53] good morning [07:54] morning BjornT, welcome to the blood bath. [07:55] hi Hobbsee :) [07:55] BjornT, would you be ok with making the BugWorkflow spec public? If so, who else should be consulted? === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [07:55] mpt: what was the problem with makign it public in the first place? [07:55] it's hardly hiding IP or something. [07:56] and it affects non-LP pepole greatly [07:56] Hobbsee, no problem in particular, it's just that Launchpad specs are on a private wiki so there's an assumption of privacy === Prognatus_ [n=bjorn@2.80-203-143.nextgentel.com] has joined #launchpad [07:56] mpt: i'm ok with it, but i guess kiko-zzz or SteveA should approve make it public. [07:56] ok [07:57] mpt: this is true - but is there a process for going "this is going to effect a lot of people, maybe we should make thsi public?" [07:57] no [07:57] well [07:57] This is the sort of thing mrevell would do [07:57] announce it in advance [07:58] though that would be announcing that it was going to happen, rather than publicizing it for discussion [08:00] mpt: do you think it should be discussed? [08:01] as in, do you think people should be able to have their say on something's that's greatly influencing them? i know the ubuntu devs who were at UDS had a fair bit to say about it, even when it was only sprung on them for discussion about an hour before the discussion started? [08:01] and changed how some of this worked, iirc [08:03] mpt: mrevell is working on an announcement, and i see that he's already talked to heno about it (who announced it to the bug squad). [08:04] Hobbsee: tbh, this spec has been discussed for a year now. discussing it another year won't take us anywhere. [08:04] Hobbsee, leave me out of this :-) [08:04] BjornT: true. unless the discussion was useful, and actually got things done [08:06] Hobbsee: it's hard to guarantee a useful discussion, though :) the fact that it has been going on for a year should mean that we're going around in circles. [08:07] well, the discussion has not included a public spec [08:07] it's hard to know [08:07] BjornT: that is true. did the sevilla discussion actually do antyhign thoguh? [08:07] Hobbsee: now we're actually do get things done, by implementing something ;) i suggest we try it out and see what we can learn from it. [08:07] BjornT: but we don't know what's supposed to be done, IMO [08:07] LaserJock: https://wiki.ubuntu.com/BugWorkflow [08:08] we just got an email like "tomorrow bug workflow and permissions are going to change" [08:08] BjornT: i'm just wondering WTF to do now that the sponsoring procedure is screwed, and how the people are not going to be able to step on other people's toes, as there's now no way to mark a non-dev as fixing a bug. [08:08] BjornT: heah, thanks for that [08:08] BjornT: if you have a solution for how to fix that problem, which isnt "oh, make a developer do it, like with importance", then i'd greatly like to hear about it. [08:08] Hobbsee: how does this affect the sponsoring procedure? [08:09] because the people being sponsored use those statuses [08:09] BjornT: because non-devs now cant assign bugs to themselves,and mark it in progress, to say "i'm fixing this" [08:10] where non-devs == people not in ~ubuntu-dev [08:10] Hobbsee: yes they can [08:10] so, let me tell you what's going to happen [08:10] BjornT: they can now, and they still can when the roll out is being done? [08:10] Hobbsee: yes [08:10] in fact, many people who fix bugs now can't get to Triaged even [08:11] if the chart on BugWorkFlow is right [08:11] i'm only going off what's been put on the devel-discuss mailing list, because as you may have noticed, the spec isnt public. so everything's second/third/fourth/fifth hand here. [08:11] some statues will simply be renamed. Unconfirmed -> New, Needs Info -> Incomplete [08:11] BjornT, why can't I see "Todo" on Launchpad bugs on staging? Will that status be introduced later? [08:11] and Rejected will be split off into Invalid and Won't Fix [08:11] that much is fine, yes [08:12] Only the ubuntu bug contact (i.e. the QA team) will be able to set a bug to Won't Fix [08:12] BjornT: the status changes aren't the problem, the problem is the permissions on who gets to change them [08:12] there's also a new status: Triaged, which only the bug contact may set [08:12] and that's it [08:12] Todo will be introduced at a later stage [08:13] ah [08:13] all other statuses will be the same, including their permissions [08:13] ok, so will anybody be able to set In Progress, Fix * ? [08:13] the main idea is that it should be easy to join the bug squad, and they will basically use New, Incomplete, and Confirmed [08:14]