[06:05] <mpt> "for example when I set a bug to needs info, I generally assign it to the reporter to make this clear"
[06:05] <mpt> Now that's interesting
[06:05] <Hobbsee> yes, there's a problem with the bug stuff.
[06:06] <Hobbsee> it totally misses the case of sponsoring. 
[06:07] <crimsun> (do we outline what "sponsoring" is in case people here aren't 100% with the terminology?)
[06:07] <Hobbsee> i'm emailing the list now
[06:07] <Hobbsee> well, -devel-discuss
[06:07] <mpt> Let me guess: casual contributor A makes a fix, but it's actually uploaded by Developer B?
[06:07] <Hobbsee> was planning to point to that while talking
[06:07] <Hobbsee> mpt: that's the one.  
[06:07] <ajmitch> mpt: pretty much, and it's very common
[06:07] <Hobbsee> contributor A should be able to assign to himself, and be able to set the status.
[06:08] <mpt> yes
[06:10] <Hobbsee> mpt: why in particular crying?
[06:11] <mpt> because I suspected this sort of problem might happen
[06:11] <mpt> though to be honest, I hadn't thought about mentoring, I was more concerned with undo
[06:12] <mpt> e.g. non-"developer" accidentally moves a bug from Todo to Triaged, and can't change it back
[06:12] <mpt> s/mentoring/sponsoring/
[06:12] <mpt> Hobbsee, LaserJock already described the sponsoring issue
[06:13] <Hobbsee> mpt: ahh
[06:14] <Hobbsee> 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] <Hobbsee> because that says "i'm working on this, no one else needs to touch it"
[06:14] <mpt> that would fix part of it
[06:14] <Hobbsee> what wouldnt it fix?
[06:17] <Hobbsee> mpt: ^
[06:17] <Hobbsee> it doenst fix the accidently sending it back, true
[06:18] <Hobbsee> 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] <Hobbsee> which is why a few of us were found, even at UDS.
[06:18] <owh> What's wrong with allowing the asignee to set the status to whatever they want?
[06:20] <Hobbsee> <the europeans are asleep.  not sure how much of a response we'll get at the moment>
[06:20] <owh> :)
[06:21] <mpt> 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] <Hobbsee> mpt: but that never happens.
[06:22] <Hobbsee> oh wait
[06:22] <Fujitsu> Not everyone uses IRC, and there's no universal medium.
[06:22] <Hobbsee> mpt: that happens a lot less
[06:22] <Hobbsee> mpt: and could be changed to "file a bug, and give me the number, for me to assign it to myself"
[06:24] <StevenK> Which is more work for developer B, whereas the current workflow has person A doing it all.
[06:25] <Hobbsee> this is true
[06:26] <owh> 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] <Hobbsee> owh: that part is fine - it just doesnt solve the other case
[06:27] <owh> Hobbsee: Then I don't understand the other case. Did I miss some part of the conversation?
[06:27] <Hobbsee> owh: [14:21]  <mpt> 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] <owh> 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] <Hobbsee> owh: correct
[06:29] <owh> 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] <Hobbsee> owh: because you can only assign the bug to yourself if you'r enot a dev.  that's the point.
[06:29] <Hobbsee> er, if you are a dev
[06:29] <mpt> owh, the difference being you can't set it to Todo because (in this scenario) you're not a "developer"
[06:30] <Hobbsee> mpt: er - can you still assign it to someone else if you're not a develoepr?
[06:30] <mpt> hmm
[06:30] <mpt> I don't know
[06:30] <ajmitch> probably not
[06:30] <owh> 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] <mpt> I guess you probably can
[06:30] <Fujitsu> mpt: Surely you can check the spec.
[06:30] <owh> :)
[06:30] <mpt> This isn't covered in the spec, iirc
[06:30] <Fujitsu> Oh, neat, a spec that doesn't spec out the feature :)
[06:31] <mpt> The BugWorkflow spec is about statuses, not about workflow
[06:31] <mpt> well, not about assignees
[06:31] <Fujitsu> Oh.
[06:31] <owh> Is there any point in doing a test? I can create a dummy bug and assign it to Hobbsee if you like.
[06:32] <Fujitsu> owh: It hasn't been rolled out yet.
[06:32] <Fujitsu> I would have thought it might be on edge, but apparently not.
[06:32] <mpt> owh, you can do that on staging.launchpad.net
[06:32] <owh> But are we saying that this behaviour has changed?
[06:32] <owh> mpt: Right now?
[06:32] <mpt> owh, afaik
[06:33] <owh> 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?
[06:35] <mpt> I can confirm that the spec doesn't mention assigning/reassigning bugs
[06:35] <ajmitch> owh: or this behaviour will change in a day or two
[06:35] <ajmitch> I don't know if it's live yet
[06:35] <Hobbsee> mpt: is there any problem with making this particular spec public?  even if you sanitize it first?
[06:35] <owh> ajmitch: Yeah, that's what we really don't know.
[06:35] <owh> Fujitsu: Hmm, I spoke too soon. My timeout just came too :)
[06:36] <mpt> Hobbsee, I'll discuss that with BjornT when he's up
[06:36] <Fujitsu> Hm, apparently just Malone doesn't work on staging. Convenient.
[06:36] <mpt> worksforme
[06:37] <owh> As ajmitch points out, this won't actually help us though will it?
[06:38] <Fujitsu> I think staging code is meant to be in sync with production, so probably not.
[06:38] <owh> Fujitsu: So, tell me again the point of staging the same version as the live version?
[06:39] <Fujitsu> Edge is meant to be more cutting-edge. Staging is just there as a testing ground
[06:40] <owh> 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] <Fujitsu> Sorry, for users to play around with on a non-production database.
[06:41] <mpt> owh, what do you mean by "staging the same version as the live version"?
[06:41] <mpt> staging.launchpad.net is, at the moment, newer code than launchpad.net
[06:41] <mpt> that's why staging.launchpad.net has the new bug statuses, and launchpad.net does not
[06:42] <Fujitsu> Ahh, so it does? I can't see them, it just times out.
[06:42] <owh> mpt: It also times out for me, if you need a specific oops: OOPS-536S13
[06:42] <ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/536S13
[06:42] <owh> Cool
[06:42] <owh> Hmm, it needs a pwd :)
[06:42] <Fujitsu> Is there any log or anything showing how the various sub-LPs compare code version-wise?
[06:43] <Fujitsu> It seems that just the bug listings timeout, while specific bugs work.
[06:45] <mpt> Fujitsu, yes, the page footer tells you exactly what revision is running
[06:46] <mpt> so launchpad.net is running r4287, while staging.launchpad.net is running r4419
[06:46] <Fujitsu> mpt: I recall I was told a couple of weeks back that they weren't comparable, as they're from different branches.
[06:46] <mpt> really? That might be true, but I don't understand why it would be
[06:47] <owh> Hobbsee: I've just assigned a bug to you (under staging), so we'll see what it does.
[06:47] <Fujitsu> I suspect that's the revision of the staging/production/edge bzr branch, which are merged from rocketfuel regularly. 
[06:47] <owh> Hobbsee: Yup, you are now the Assignee.
[06:47] <owh> https://bugs.staging.launchpad.net/ubuntu/+source/gphpedit/+bug/73310
[06:47] <ubotu> Launchpad bug 73310 in gphpedit "Selected text colour does not follow theme" [Low,In progress]   - Assigned to Onno Benschop (onno-itmaze)
[06:47] <owh> This is a STAGING bug, not a real one!
[06:48] <Hobbsee> yep
[06:48] <mpt> ubotu, you silly wabbit
[06:49] <stub> 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)
[06:50] <owh> Hobbsee: I'm now taking it back to see if I can change the status.
[06:50] <Fujitsu> stub: Ah, that's what I thought.
[06:51] <owh> Fujitsu: I can change the Status, but I cannot change the Importance.
[06:51] <mpt> ok, thanks stub 
[06:51] <owh> mpt: Hey, this is still the old levels.
[06:51] <mpt> owh, I was just there ten minutes ago seeing the new ones
[06:51] <owh> mpt: I thought that the staging version was the one that is going to be rolled out.
[06:51] <Fujitsu> owh: Mortals can't change the status to wontfix, triaged, or todo.
[06:51] <Hobbsee> 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] <Fujitsu> Hobbsee: It seems they can.
[06:52] <Hobbsee> Fujitsu: if the statuses go thru as intended, though
[06:52] <mpt> Hobbsee, arguably Fix Released isn't the appropriate resolution for that case anyway
[06:52] <Fujitsu> The only statuses that aren't accessible to the unprivileged are wontfix, triaged and todo.
[06:52] <owh> 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] <mpt> Won't Fix is
[06:53] <Hobbsee> mpt: "upstream has released the fix for this" - it is the appropriate resolution
[06:53] <Fujitsu> mpt: No, Fix Released is.
[06:53] <mpt> 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] <Hobbsee> mpt: the new release has often already occured.
[06:53] <Fujitsu> Well, I think this is presuming the release is already here.
[06:53] <Fujitsu> Wont Fix might work, but Fix Released is probably better.
[06:54] <Hobbsee> are you saying that now, the ubuntu bug should have wontfix, and the upstream bugs should be linked, etc, etc, etc
[06:54] <owh> On this page, I only see the current status options: https://bugs.staging.launchpad.net/ubuntu/+source/gphpedit/+bug/73310
[06:54] <ubotu> Launchpad bug 73310 in gphpedit "Selected text colour does not follow theme" [Low,In progress]   - Assigned to Onno Benschop (onno-itmaze)
[06:54] <Hobbsee> mpt: ^
[06:54] <mpt> Hobbsee, that's how I always imagined it working (but probably no-one ever told the Ubuntu developers)
[06:54] <owh> :)
[06:55] <Hobbsee> mpt: that's a shitload of extra work, for very little gain
[06:55] <Hobbsee> mpt: and i'm not even going to go into the latter issue.  yet.
[06:56] <mpt> Hobbsee, what's the difference in work between moving a bug to Fix Released, and moving it to Won't Fix?
[06:57] <Hobbsee> 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"
[06:57] <Hobbsee> i can tell you now - the upstream bugs wont be linked a lot of the time, because it's a lot of extra work
[06:57] <Hobbsee> mpt: "wont fix" really means "yes, we know it's a bug, but we're not going to fix it"
[06:57] <Hobbsee> mpt: whereas "fix released" means "it's a bug, it's been fixed, and it's in the archives"
[06:58] <Hobbsee> there's a big difference there
[06:58] <Hobbsee> although, if WONTFIX isnt shown on the default search, it's not a major issue.
[06:58] <Fujitsu> wontfix is a semi-closed state, or should be at least.
[06:58] <owh> "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] <mpt> Hobbsee, I understand what Ubuntu developers have been taking the statuses to mean
[06:59] <mpt> What I don't understand is your "extra work" comment
[06:59] <Hobbsee> 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] <mpt> owh, whoa, how did you do that
[06:59] <mpt>  oh wait
[06:59] <owh> mpt: Do what?
[06:59] <mpt> That *is* the new statuses
[06:59] <mpt> but we can see only a subset of them
[07:00] <mpt> Notice how they have new names
[07:00] <Hobbsee> mpt: the having to look up the upstream bug, link it, wait for the status of the upstream bug to update
[07:00] <mpt> Hobbsee, why would you have to do that any more than you do now?
[07:01] <Hobbsee> 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] <owh> 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] <mpt> hrmm
[07:02] <owh> Hobbsee: Is that what you mean, or should I not put words in your mouth?
[07:03] <mpt> as in, "hey, whaddya mean it won't be fixed"?
[07:03] <Hobbsee> owh: kidna.
[07:03] <owh> mpt: Yes.
[07:03] <Hobbsee> mpt: yeah.  
[07:03] <mpt> This is why I wanted to call the status "Won't Fix *Here*"
[07:03] <owh> Hobbsee: Does it have prickles this kidna of yours?
[07:03] <mpt> (back when I still wanted it at all)
[07:04] <Fujitsu> owh: Heheh.
[07:04] <ajmitch> "Won't Fix" will really confuse some users
[07:04] <mpt> but I guess even that wouldn't have resolved all the confusion
[07:04] <owh> mpt: From my perspective, fix released means that the fix exists, it will come when it comes.
[07:04] <Fujitsu> I still think SEP is better :P
[07:04] <Fujitsu> owh: No, that is *not* what Fix Released means.
[07:04] <Hobbsee> 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] <owh> Fujitsu: ROTFL, I chocked on that. Bad. Coughing and spluttering.
[07:05] <Hobbsee> SEP rocks.k
[07:05] <mpt> Well, *cough*, Fix Released wasn't intended to be used the way Ubuntu developers use it either
[07:05] <Hobbsee> mpt: yeah, true that.  we've had arguments on that already :P
[07:05] <Fujitsu> Version tracking would make that practical.
[07:05] <owh> 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] <mpt> I regret to say I was a bit of an architecture astronaut back then
[07:05] <Fujitsu> (as well as generally being useful)
[07:06] <mpt> overestimating the status-flipping people would be interested in doing
[07:06] <Fujitsu> Gah, about to be dragged out by my hair, apparently.
[07:06] <mpt> but I'm cured now
[07:06] <Hobbsee> of course...
[07:06] <ajmitch> it was beaten out of you?
[07:07] <owh> 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] <Hobbsee> 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] <mpt> owh, I don't know what you mean, unless you're referring to the Incomplete status in particular
[07:08] <owh> mpt: No, you said "overestimating the status-flipping people would be interested in doing", that's what I was responding to.
[07:08] <mpt> ajmitch, I beat it out of myself :-) Nowadays I think there should be five bug statuses
[07:08] <Hobbsee> mpt: 
[07:08] <Hobbsee> Another workflow example that requires this is a member of bugsquad
[07:08] <Hobbsee> who discovers that a bug in a package pulled directly from Debian has
[07:08] <Hobbsee> been fixed in a newer version, and needs to set the status to "Fix
[07:08] <Hobbsee> Released" with a comment indicating the version in which it is fixed.
[07:08] <Hobbsee> also occurs
[07:09] <ajmitch> ah, versions
[07:09] <mpt> owh, sorry, I still don't understand
[07:11] <owh> 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] <mpt> owh, I mean, I overestimated the time which people would be interested in spending on changing the status of bug reports
[07:13] <mpt> for example
[07:13] <owh> ROTFL
[07:13] <owh> mpt: Sorry.
[07:13] <owh> mpt: They don't want to spend any time at all:)
[07:13] <mpt> 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] <owh> Sure
[07:14] <mpt> then when Gutsy was released as 7.10, all those Fix Committed bugs would be changed to Fix Released
[07:14] <mpt> but that's infeasible
[07:14] <Hobbsee> that's just painful
[07:14] <owh> Yeah, my understanding of Fix Committed is that it's been sent to the queue.
[07:14] <Hobbsee> as we tend to use committed for other stuff
[07:14] <mpt> largely because we don't have mass status changing, but only largely, not completely
[07:15] <Hobbsee> 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] <mpt> partly because people just wouldn't be bothered
[07:15] <owh> mpt: Mass status changing is a ****VERY**** bad idea IMHO.
[07:15] <mpt> maybe
[07:15] <mpt> Mass other-stuff changing is needed
[07:15] <Hobbsee> er, we still have confirmed in there?
[07:15] <mpt> (e.g. mass milestone targeting)
[07:16] <owh> Hobbsee: Yup, I see that too.
[07:16] <owh> At the moment I understood it to mean "Me too"
[07:16] <mpt> "Triaged - may only be set by a bug contact"
[07:16] <owh> s/it/Confirmed/
[07:16] <mpt> (that's from the spec)
[07:17] <mpt> so anyone can mark as Confirmed, only bug contacts can mark as Triaged
[07:17] <owh> mpt: How is a bug contact defined?
[07:17] <Hobbsee> owh: people subscribed to the bugs of a package
[07:17] <Hobbsee> owh: can be a person or team
[07:18] <Hobbsee> then again...
[07:18] <owh> So, the sequence is New -> Need Info -> Confirmed -> Triaged -> In Progress -> Fixed.
[07:18] <Hobbsee> by assigning to yourself, you're saying that you are taking responsiblity of the bug.
[07:19] <owh> Yeah, that's what I understood it to be.
[07:19] <Hobbsee> in which case, you should be able to set whatever you like.
[07:19] <Hobbsee> and it's yoru fault if you get it wrong.
[07:19] <owh> Yup
[07:19] <owh> :)
[07:19] <Hobbsee> which only has an inconvenient side effect of getting lots of bugmail from them.
[07:20] <Hobbsee> owh: heh.  i have enough, being on the kubuntu council
[07:20] <owh> 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] <mpt> owh, you missed Todo
[07:20] <owh> Hobbsee: See, you should have stayed with Gnome :)
[07:20] <Hobbsee> owh: i cant stand gnome.
[07:21] <owh> mpt: Yeah, between Triaged and In Progress
[07:21] <Hobbsee> mpt: TODO isnt there
[07:21] <owh> Hobbsee: I put up with it.
[07:21] <mpt> Hobbsee, it is for "developers"
[07:21] <owh> mpt: Indeed, Hobbsee makes a fair point :)
[07:21] <Hobbsee> mpt: which is, sorry?
[07:21] <owh> mpt: I'm a developer. I download source, play with it, fix stuff.
[07:21] <Hobbsee> mpt: developers != the people in ~ubuntu-dev.
[07:21] <owh> mpt: That's the real problem.
[07:21] <Hobbsee> mpt: developers > the people in ~ubuntu-dev.
[07:22] <owh> s/>/>>>/
[07:22] <mpt> huh
[07:22] <mpt> you're right
[07:22] <mpt> I don't see Todo for a bug report about Launchpad itself
[07:22] <mpt> that's very strange
[07:22] <owh> :)
[07:23] <Hobbsee> it's saying "TOO MANY STATUSES.  NO MORE!
[07:23] <owh> Hobbsee: What about a slider, you know between borked and fixed :)
[07:23] <LaserJock> well
[07:23] <Hobbsee> haha
[07:24] <LaserJock> I'm not sure if I can really see a case where a status should be tied to a group
[07:24] <owh> Infinite status.
[07:24] <LaserJock> seems to me like all status's should be available to everybody
[07:24] <owh> Yup, I was just about to write that :)
[07:25] <LaserJock> do we have a reason for making only some statuses available to some poeple?
[07:25] <owh> 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] <Hobbsee> LaserJock: so that the odd few people cant abuse it.
[07:26] <LaserJock> owh: why not?
[07:26] <LaserJock> Hobbsee: so?
[07:26] <LaserJock> we let people do things all the time
[07:26] <Hobbsee> LaserJock: i'm not saying it's a good one - that's jsut the reason
[07:26] <Hobbsee> afaik
[07:26] <LaserJock> the whole wiki is open to anyone, why not the bug tracker
[07:27] <owh> 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] <LaserJock> as long as they can't really mess something up
[07:27] <LaserJock> owh: why? if you fixed something you should be able to mark it as such
[07:27] <LaserJock> if people are doing the work they should be able to show it
[07:28] <owh> 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] <LaserJock> uploading is the only thing that really separates devs from non-devs
[07:28] <LaserJock> and that's soyuz, not malone ;-)
[07:28] <LaserJock> owh: I'm saying, the only difference, where bug reports are concerned, is that I can acutually upload and you can't
[07:29] <LaserJock> but you can do the work, you can do the triaging, you can do everything but upload
[07:29] <owh> LaserJock: Works for me. Of course you could mark a bug as fixed when it has not been though.
[07:29] <LaserJock> sure
[07:29] <LaserJock> people make mistakes
[07:29] <LaserJock> no biggie, we learn and move on
[07:30] <LaserJock> I'm afraid if we start saying "No we don't trust you" then nobody is going to want to help out
[07:30] <owh> 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] <owh> Hmm, I typed all that, then you came along with your comment.
[07:31] <owh> I agree. I'd rather live in a society where we do trust people.
[07:31] <LaserJock> well, we get bugmail, say "hmm, we need to educate this guy a little", and you learn
[07:31] <LaserJock> I've rarely seen cases when a person continually messed stuff up
[07:31] <owh> Yeah. Cool. All good. So, we give everyone all privileges, except upload. Works for me.
[07:32] <LaserJock> well, that's essentially the case as it is now
[07:32] <LaserJock> Importance is the only thing that I'm aware of
[07:32] <LaserJock> and I don't know that many people really care about that ;-)
[07:32] <LaserJock> I don't use it
[07:32] <LaserJock> maybe some do
[07:32] <owh> LaserJock: That's because you can't :)
[07:32] <LaserJock> sure I can
[07:33] <owh> As a member of which team?
[07:33] <LaserJock> ubuntu-qa
[07:33] <owh> Fair enough.
[07:33] <owh> Well now that we've solved that...
[07:34] <Hobbsee> heh
[07:34] <Hobbsee> yes, it happens occasionally
[07:34] <LaserJock> people were routinely abusing Importance (*every* bug I report is important)
[07:34] <mpt> bug 2553
[07:34] <ubotu> 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] <owh> mpt: So, can we all have all Status options, or will we have to wait for that?
[07:35] <owh> mpt: Ask jijobaby for a status report :)
[07:35] <mpt> owh, I don't know, sorry
[07:35] <LaserJock> well, my suggestion would be to work out workflows for developers (~ubuntu-dev) and non-developers
[07:35] <LaserJock> then figure out how statuses and permissions best suit the workflow
[07:36] <owh> 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] <LaserJock> 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] <owh> 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] <Hobbsee> mpt: oh neat.  that's a changed assignee, and a spammed bug report
[07:39] <owh> Hobbsee: From me? gphpedit?
[07:39] <Hobbsee> owh: no, the bug mpt mentioned
[07:40] <owh> Hobbsee: Sorry, I thought you were looking in your mailbox and noticing stuff from the staging server.
[07:40] <Hobbsee> nah
[07:40] <Hobbsee> i dont seem to have that yet, though
[07:40] <Hobbsee> or else it's lost amongst all the other bugmail
[07:41] <owh> Hobbsee: I don't have it either. If all works as it should, perhaps it won't generate email :)
[07:42] <LaserJock> 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] <LaserJock> and allow anybody to assign themselves
[07:42] <owh> Yup.
[07:42] <Hobbsee> LaserJock: +1
[07:42] <Hobbsee> guess we'll need to wait for input from the powers that be, though
[07:43] <Hobbsee> owh: he's a core dev, too
[07:43] <owh> Hobbsee: :)
[07:44] <RAOF> He is now.  Incidentally, congratulations LaserJock :)
[07:45] <LaserJock> bah
[07:46] <LaserJock> thanks RAOF 
[07:53] <BjornT> good morning
[07:54] <Hobbsee> morning BjornT, welcome to the blood bath.
[07:55] <BjornT> hi Hobbsee :)
[07:55] <mpt> BjornT, would you be ok with making the BugWorkflow spec public? If so, who else should be consulted?
[07:55] <Hobbsee> mpt: what was the problem with makign it public in the first place?
[07:55] <Hobbsee> it's hardly hiding IP or something.
[07:56] <Hobbsee> and it affects non-LP pepole greatly
[07:56] <mpt> Hobbsee, no problem in particular, it's just that Launchpad specs are on a private wiki so there's an assumption of privacy
[07:56] <BjornT> mpt: i'm ok with it, but i guess kiko-zzz or SteveA should approve make it public.
[07:56] <mpt> ok
[07:57] <Hobbsee> 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] <mpt> no
[07:57] <mpt> well
[07:57] <mpt> This is the sort of thing mrevell would do
[07:57] <mpt> announce it in advance
[07:58] <mpt> though that would be announcing that it was going to happen, rather than publicizing it for discussion
[08:00] <Hobbsee> mpt: do you think it should be discussed?
[08:01] <Hobbsee> 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] <Hobbsee> and changed how some of this worked, iirc
[08:03] <BjornT> 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] <BjornT> Hobbsee: tbh, this spec has been discussed for a year now. discussing it another year won't take us anywhere.
[08:04] <mpt> Hobbsee, leave me out of this :-)
[08:04] <Hobbsee> BjornT: true. unless the discussion was useful, and actually got things done
[08:06] <BjornT> 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] <LaserJock> well, the discussion has not included a public spec
[08:07] <LaserJock> it's hard to know
[08:07] <Hobbsee> BjornT: that is true.  did the sevilla discussion actually do antyhign thoguh?
[08:07] <BjornT> 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] <LaserJock> BjornT: but we don't know what's supposed to be done, IMO
[08:07] <BjornT> LaserJock: https://wiki.ubuntu.com/BugWorkflow
[08:08] <LaserJock> we just got an email like "tomorrow bug workflow and permissions are going to change"
[08:08] <Hobbsee> 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] <LaserJock> BjornT: heah, thanks for that
[08:08] <Hobbsee> 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] <BjornT> Hobbsee: how does this affect the sponsoring procedure?
[08:09] <LaserJock> because the people being sponsored use those statuses
[08:09] <Hobbsee> BjornT: because non-devs now cant assign bugs to themselves,and  mark it in progress, to say "i'm fixing this"
[08:10] <Hobbsee> where non-devs == people not in ~ubuntu-dev
[08:10] <BjornT> Hobbsee: yes they can
[08:10] <BjornT> so, let me tell you what's going to happen
[08:10] <Hobbsee> BjornT: they can now, and they still can when the roll out is being done?
[08:10] <BjornT> Hobbsee: yes
[08:10] <LaserJock> in fact, many people who fix bugs now can't get to Triaged even
[08:11] <LaserJock> if the chart on BugWorkFlow is right
[08:11] <Hobbsee> 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] <BjornT> some statues will simply be renamed. Unconfirmed -> New, Needs Info -> Incomplete
[08:11] <mpt> BjornT, why can't I see "Todo" on Launchpad bugs on staging? Will that status be introduced later?
[08:11] <BjornT> and Rejected will be split off into Invalid and Won't Fix
[08:11] <Hobbsee> that much is fine, yes
[08:12] <BjornT> Only the ubuntu bug contact (i.e. the QA team) will be able to set a bug to Won't Fix
[08:12] <LaserJock> BjornT: the status changes aren't the problem, the problem is the permissions on who gets to change them
[08:12] <BjornT> there's also a new status: Triaged, which only the bug contact may set
[08:12] <BjornT> and that's it
[08:12] <BjornT> Todo will be introduced at a later stage
[08:13] <mpt> ah
[08:13] <BjornT> all other statuses will be the same, including their permissions
[08:13] <LaserJock> ok, so will anybody be able to set In Progress, Fix * ?
[08:13] <BjornT> 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] <Hobbsee> BjornT: where the bug squad is for triaging?
[08:14] <BjornT> after they have made sure that the bug reports are good bug reports, they will move the bug to Confirmed
[08:14] <BjornT> since anyone can set a bug to Confirmed, it's hard to know about the "quality" of the triaging
[08:15] <BjornT> so now the QA team can look at all the Confirmed bugs, and move the good ones to Triaged (so that a developer can look at it), or move it back to Incomplete
[08:15] <BjornT> if the QA team sees that someone triages bugs well, they can promote him to the QA team, or something like that
[08:16] <LaserJock> ok, so this workflow seems ok for Main bugs or what I'd think of a traditional bugs
[08:16] <LaserJock> but it doesn't really seem to take into account the large amount of workflow "bugs" we do
[08:16] <LaserJock> i.e. sponsorship, archive admin'ing
[08:16] <BjornT> LaserJock: yes, anyone will be albe to set In Progress, and Fix *. we didn't want to bother restricting those statuses
[08:16] <Hobbsee> this seems that the number of people joining qa is going to be greatly increased
[08:16] <Hobbsee> BjornT: oh good.  that wasnt clear in the email
[08:17] <LaserJock> so people can mark a bug In Progress or Fix Released, but not Confirmed?
[08:17] <LaserJock> that's interesting :-)
[08:17] <Hobbsee> LaserJock: s/confirmed/triaged/
[08:17] <LaserJock> hmm, right, I thought confirmed was retained for something
[08:18] <LaserJock> so people can jump around "triaging"
[08:18] <Hobbsee> yes
[08:18] <LaserJock> well, I guess that works
[08:18] <owh> Hmm, so I'm an independent person. I know about my pet project. Can I set the status to Confirmed?
[08:18] <BjornT> owh: yes you can
[08:19] <owh> BjornT: I don't need to be a member of any team?
[08:19] <BjornT> owh: no, anyone can set a bug to Confirmed
[08:20] <BjornT> Hobbsee: i'll talk to mrevell to make sure that this is made clear in his announcement
[08:20] <owh> BjornT: So, am I understanding correctly that a Triaged Bug is after Confirmed, but before ToDo/In Progress?
[08:20] <LaserJock> yes, because I think heno's email said that we'd have the full implementation like tomorrow
[08:20] <BjornT> owh: that's right
[08:20] <Hobbsee> owh: triaged means "i have enough info, please someone fix me"
[08:20] <Hobbsee> BjornT: cool, thanks.  
[08:21] <owh> So the spec we just saw at: https://wiki.ubuntu.com/BugWorkflow doesn't actually show "Confirmed"
[08:21] <owh> In fact it says: rename "Confirmed" -> "Triaged"
[08:21] <LaserJock> it also seems to indicate that only developers will be able to set In Progress and ToDO
[08:23] <LaserJock> the design seems to separate the statuses into ones for "triagers" and "developers"
[08:23] <LaserJock> however I don't see how we are going to really be able to separate/define those groups well enough for restrictions
[08:24] <owh> The spec also says: "Add a QA team to products and distributions. If a QA team is set, normal users can only use a restricted set of bug statuses."
[08:24] <owh> That contradicts what BjornT just told us.
[08:24] <BjornT> owh: yeah, the page is a but outdated. here's what we drew up at UDS: http://people.ubuntu.com/~bjorn/bug-workflow.png
[08:26] <BjornT> owh: that wiki page (on wiki.ubuntu.com) is the old discussion, which got a bit out of control. it doesn't describe exactly what will be done.
[08:27] <owh> So, the only status that the bug-squad has "extra" is Triaged, all other status flags can be set by anyone (either the assignee, or a ubuntu-dev) ?
[08:28] <owh> BjornT: Or can anyone set anything?
[08:30] <BjornT> owh: well, it's ubuntu-qa that has Triaged extra, and they also have Won't Fix. all other statuses can be set by anyone (Todo will be restricted as well, but we won't add it until later)
[08:32] <owh> BjornT: So, if I am aware of a bug and I can fix it, but I've got a few other bugs as well, and I'm not a ubuntu-dev, I cannot set a bug I've assigned to myself as "ToDo", so I can manage my own workflow?
[08:33] <Hobbsee> owh: you have to set it to inprogress, and assign yourself
[08:34] <BjornT> owh: well, that won't be a problem atm, since we haven't added Todo.
[08:34] <owh> BjornT: I'm just looking into the future.
[08:34] <owh> Hobbsee: Yes, but inprogress implies that I'm doing something does it not?
[08:34] <BjornT> owh: after you've fixed it, how will you get the fix uploaded to the ubuntu archive?
[08:34] <Hobbsee> BjornT: subscribing ubuntu-universe-sponsors
[08:34] <owh> BjornT: I ask a friend :)
[08:35] <Hobbsee> BjornT: and following that procedure
[08:35] <owh> BjornT: The idea being that I as an external person can do everything except upload. That means I can help easier without adding to someone else's workload.
[08:35] <BjornT> Hobbsee: would it be feasible to ask ubuntu-universe-sponsors to set the bug to Todo for owh?
[08:36] <Hobbsee> BjornT: um...not really.
[08:36] <Hobbsee> BjornT: because ubuntu-universe-sponsors is only for getting your stuff uploaded - it's not for requests of help, or antyhing else
[08:36] <Hobbsee> just like ubuntu-archive is
[08:37] <Hobbsee> we make that very clear, else people file bugs saying "this needs a merge, please do it" or similar, and subscribe us
[08:40] <BjornT> Hobbsee: ok. is there  a wiki page describing this process?
[08:41] <Hobbsee> BjornT: somewhat.  https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[08:41] <Hobbsee> BjornT: it's still a bit of a WIP
[08:41] <Hobbsee> but it's what we're using at the moment
[08:42] <Hobbsee> it's very easy to flood the sponsors queue - so making them to as little extra work as possible is good
[08:46] <BjornT> Hobbsee: ok. i'll have to think about how that would work with a new (restricted) Todo status.
[08:46] <Hobbsee> BjornT: right
[08:46] <BjornT> but now, it's time for breakfast
[08:46] <owh> BjornT: Afternoon Tea you mean :)
[09:11] <carlos> morning
[09:17] <Hobbsee> morning carlos 
[10:36] <seb128> hi
[10:37] <carlos> seb128: hi
[10:37] <seb128> looks like the armagetron task on bug #37316 can't be closed, does anybody known if that's a known issue?
[10:37] <ubotu> Launchpad bug 37316 in armagetron "Please sync armagetron (universe) with Debian 0.2.8.2 (testing)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/37316
[10:37] <seb128> armagetron is a binary package, source is armagetronad which already has a task
[10:38] <seb128> when closing it tries to reassign to the source and error on "This bug has already been reported on armagetronad (ubuntu)."
[10:43] <BjornT> seb128: this should be due to bug 81014, so you should be able to close the task after the rollout today.
[10:43] <ubotu> Launchpad bug 81014 in malone "Don't assume entered package is a binary package" [High,Fix committed]  https://launchpad.net/bugs/81014 - Assigned to Gavin Panella (allenap)
[10:43] <seb128> BjornT: cool, thanks
[11:23] <carlos> dneary_: hi, around?
[12:27] <dneary_> hi carlos
[12:28] <carlos> dneary: hi
[12:28] <carlos> dneary: I'm cleaning up pending import files for translations
[12:28] <carlos> dneary: and saw a zh.po for wengo
[12:29] <carlos> it's not auto approved because you shouldn't use that, instead, you should use either zh_CN or zh_TW 
[12:31] <carlos> and I wonder which one is that for
[12:32] <carlos> dneary: do you know it?
[12:33] <carlos> zh_CN == 'Simplified Chinese' and zh_TW == 'Traditional Chinese'
[12:35] <dneary> carlos: I know that I have a zh_CN translation in there already
[12:36] <dneary> I don't know if it's the same as the zh (the zh translation was done by someone here at Wengo, and is dormant)
[12:36] <carlos> dneary: Launchpad has translations for both, but no one comes from files imported by you, so I don't know which one to choose... and I don't want to break anything
[12:36] <carlos> dneary: should I discard that translation then?
[12:37] <dneary> Which branch is this for?
[12:40] <carlos> 2.1
[12:45] <mikl_> Is it not possible to create a new bzr branch on launchpad that's not in a particular project?
[12:50] <mwhudson> yes, put "+junk" instead of a project name
[01:01] <MehdiHassanpour> hi :-)
[01:01] <MehdiHassanpour> any one knows where can I ask translation related questions ?
[01:03] <Watersevenub> MehdiHassanpour, maybe in the channel of your country or perhaps in #ubuntu-translators. If related to the tool itself (launchpad), in here.
[01:04] <mikl_> mwhudson: but where do I create a new branch - The only option I can find is to register an external branch...
[01:04] <MehdiHassanpour> Watersevenub: ty :-)
[01:04] <mwhudson> mikl_: with 'bzr push'
[01:05] <mikl_> mwhudson: mmkay - is there a howto somewhere?
[01:05] <mwhudson> https://help.launchpad.net/CreatingAHostedBranch
[01:06] <mikl_> mwhudson: ok, thank you :)
[01:06] <mwhudson> in the new release (due in a matter of hours)
[01:06] <mwhudson> this page will be linked to from various Help tabs
[01:09] <mikl_> ok, but with this doc, I still have to push it into a directory...
[01:09] <mikl_> I guess I can just push it into Drupal...
[01:10] <mwhudson> push to ~username/+junk/branchname
[01:11] <mwhudson> the page doesn't mention this possibility, maybe it should
[01:11] <mwhudson> mrevell: hi :)
[01:12] <mwhudson> it's mentioned on here https://help.launchpad.net/FeatureHighlights/EasyBranching
[01:12] <mikl_> yes, that might be a good idea - I just don't particularly like that label - ohyes, just push my precious source code into the junk department :)
[01:12] <mrevell> mwhudson: hi
[01:13] <mwhudson> mrevell: remember this page https://help.launchpad.net/CreatingAHostedBranch ?
[01:13] <mrevell> mwhudson: yeah
[01:13] <mwhudson> mikl_: i think it's meant to be a subtle hint that you should set up a project, etc
[01:13] <mrevell> the junk suggestion - noted
[01:13] <mwhudson> mrevell: do you think it should mention the +junk pseudo project?
[01:13] <mrevell> :)
[01:13] <mwhudson> ok
[01:14] <mikl_> oops, I get a 500 Internal Error when trying to browse one codebrowse.launchpad.net
[01:14] <mikl_> http://codebrowse.launchpad.net/~mikl/drupal/mikl-danish/files
[01:15] <cprov> gmorning all !
[01:16] <mwhudson> mikl_: wfm
[01:16] <mikl_> wfm?
[01:16] <mwhudson> works for me
[01:17] <mwhudson> and i can't see any errors in the logs, strange
[01:17] <mwhudson> oh now i can
[01:18] <mikl_> mwhudson: it's only if you click on a file
[01:18] <mwhudson> yeah
[01:18] <mikl_> or event_da.po, more specifically
[01:18] <mwhudson> feeding utf-8 to expat when it expects latin-1 or something similarly hilarious
[01:19] <mikl_> oh :(
[01:20] <mwhudson> https://bugs.launchpad.net/loggerhead/+bug/117799
[01:20] <ubotu> Launchpad bug 117799 in loggerhead "Error parsing non-ascii content" [Undecided,Unconfirmed]  
[01:21] <mwhudson> though i don't really know what you can do here
[01:21] <mwhudson> you have a file, in some encoding
[01:22] <mikl_> I guess I could encode it as iso-8859-1 - that usually works everywhere
[01:22] <mwhudson> and you want to send lines from that file to the user's browser
[01:22] <mwhudson> (in utf-8, i expect)
[01:22] <mikl_> But I don't know if bzr will get confused if I just iconv the file...
[01:23] <mwhudson> well, it's a general problem
[01:23] <mikl_> and even worse, I don't know if Drupal will eat it...
[01:23] <mwhudson> you shouldn't have to change your data to appease the tools
[01:24] <mikl_> sigh. Character encodings.
[01:24] <mikl_> I only everyone had always used unicode always everywhere.
[01:25] <mikl_> /^I/If/
[01:29] <mikl_> mwhudson: actually, the criminal file is in iso-8859-1 - The .po files i have in utf-8 work fine
[01:30] <mwhudson> mikl_: so i got it wrong
[01:30] <mwhudson> feeding latin-1 to expat when it wanted utf-8
[01:35] <mikl_> I have another related bug...
[01:36] <mikl_> If you view http://codebrowse.launchpad.net/~mikl/drupal/mikl-danish/bundle/mikkel%40hoegh.org-20070620110720-6m5woqzje878nztk/bundle.txt the content is served as iso-8859-1, but is really utf-8 - so all the danish characters are mangled
[01:38] <mwhudson> fun
[01:39] <mikl_> I'll see if it is already reported
[01:40] <mwhudson> you can't really win here can you?
[01:41] <mwhudson> the bundle could touch files that are in different encodings
[01:42] <mikl_> yes, I guess that that is the issue here...
[01:43] <mikl_> but now I've pushed all files up to UTF-8, I get another 500 error when viewing revision 3
[01:43] <mikl_> I don't know if that is a separate issue
[01:44] <mikl_> Sigh
[01:45] <mwhudson> mikl_: no, it's the same, the diff will include the old troublesome data
[01:45] <mikl_> ah yes...
[01:46] <Hobbsee> morning kiko!
[01:52] <kiko> hey Hobbsee 
[02:21] <ubotu> New bug: #121331 in launchpad-bazaar "supermirror-pull mirror sometimes hangs" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121331
[03:11] <carle> when there is this info:" 	 represents a space character. Enter a space in the equivalent position in the translation."
[03:12] <carle> Should I just press space behind the translation
[03:17] <carle> anyone?
[03:17] <kiko> carle, yes.
[03:19] <carle> thank you
[03:25] <ubotu> New bug: #121340 in malone "Support RT bug watches" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121340
[04:00] <ubotu> New bug: #121348 in malone "BugZilla VERIFIED WONTFIX should map to Won't Fix" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121348
[04:02] <statik> BjornT: reviewers meeting?
[04:02] <bac> me
[04:02] <barry> me
[04:03] <BjornT> statik: oh, right, forgot about that, i'm currently planning for 1.1.7 with kiko :/
[04:03] <BjornT> flacoste: could you chair this meeting, please?
[04:03] <flacoste> BjornT: ok
[04:03] <BjornT> thanks
[04:03] <BjornT> i'll be here partially
[04:04] <flacoste> Welcome to the non .au reviewers meeting
[04:04] <flacoste> for the next 45 minutes, we'll be coordinating reviewing activities
[04:04] <flacoste> == Agenda ==
[04:04] <flacoste>  * Roll call
[04:04] <flacoste>  * Next meeting
[04:04] <flacoste>  * Queue status.
[04:04] <flacoste>  * Preimplementation call status/progress (barry in .eu)
[04:04] <flacoste> so who's here today?
[04:04] <barry> me 2
[04:04] <flacoste> not everyone at the same time please
[04:05] <bac> me
[04:05] <flacoste> salgado: ping
[04:05] <salgado> me
[04:05] <statik> me
[04:06] <kiko> em
[04:06] <flacoste> ok, next meeting
[04:06] <flacoste> a lot of the reviewers will be in London next week
[04:07] <flacoste> should we still hold a meeting?
[04:07] <flacoste> i mean all reviewers will be in London except bac, i think
[04:07] <barry> i won't be in london
[04:08] <flacoste> and barry
[04:08] <bac> barry and i can meet.  :)
[04:08] <barry> bac: yeah, who needs 'em?!
[04:09] <barry> flacoste: either way is fine with me
[04:10] <flacoste> i think we could still hold one
[04:10] <flacoste> the meeting time falls in a non-scheduled time slot
[04:10] <flacoste> so, next meeting Wed June 27th at 14UTC
[04:11] <flacoste> any objections?
[04:11] <flacoste> hmm, i have
[04:11] <flacoste> !
[04:12] <flacoste> i mess up tz calculation and the meeting falls in the Answer Tracker planning session!
[04:12] <barry> flacoste: we're pretty early in the cycle next week, right?  maybe there won't be enough to discuss and we can safely skip it?
[04:13] <bac> isn't 1400 UTC on wed our normal bat time?
[04:13] <flacoste> it is
[04:14] <flacoste> i would suggest skipping it or moving it to 10UTC or 17UTC
[04:14] <flacoste> comments?
[04:15] <barry> 17utc would be better.  not that i don't mind getting up at 6am now and then :)
[04:15] <flacoste> anyone having a problem with 17UTC?
[04:15] <barry> but i'm not sure i can /think/ very well at 6am :)
[04:15] <flacoste> 3
[04:15] <flacoste> 2
[04:15] <flacoste> 1
[04:16] <Hobbsee> barry: it's not possible.  i've tried.
[04:16] <barry> Hobbsee: i'm a musician.  the only time i'm up at 6am is when i haven't gone to bed the night before :)
[04:16] <Hobbsee> barry: *grin*.  sounds like sound tech.  same thing :)
[04:17] <Hobbsee> flacoste: timeanddate.com
[04:17] <barry> Hobbsee: indeed!
[04:18] <flacoste> after consideration, 16UTC would be a better time i think
[04:18] <barry> 16utc is fine too
[04:19] <flacoste> ok, then Wed Jun 27th at 16UTC (2 hours later than usual) it will be!
[04:19] <flacoste> moving one to 'Queue status'
[04:19] <bac> elliot and i have a meeting at 1500 that may run long
[04:21] <flacoste> bac, I'll be near elliot at that time and can poke him about that :-)
[04:22] <flacoste> queue is looking a lot better than last week
[04:23] <flacoste> 14 open reviews, 8 over the service level but most are on the limit
[04:23] <flacoste> oldest one is a DB review, after that is a post-merge review assigned to BjornT
[04:24] <flacoste> bac and barry also have one review over SLA
[04:24] <bac> i think mine was assigned today  :(
[04:25] <flacoste> bac: that's possible
[04:25] <barry> as was mine
[04:25] <flacoste> which points out to a problem with the review assignment
[04:25] <barry> iirc, it's a fairly longstanding complaint
[04:26] <kiko> barry, flacoste: why do we need to have assignment be done separately?
[04:26] <barry> flacoste: what do you think of an amendment to the policy where reviewers can snag branches off the general queue themselves.  for example, if i have a hour to kill, i can grab a branch without waiting for its assignment.  also, i might tend to snag branches in areas i know something about (could be a plus or minus)
[04:27] <flacoste> barry: i think this is allowed
[04:27] <barry> flacoste: oh, well then nm :)
[04:27] <flacoste> it's kind of a variation of the process where a dev hunts for a reviewer on IRC bypassing the assignment process
[04:28] <flacoste> kiko: did you mean something similar to what barry just proposed?
[04:28] <kiko> yes.
[04:29] <flacoste> fine, I'll put this for discussion also in the .au meeting, but I think barry initiative is fine
[04:29] <flacoste> so we can start experimenting with that
[04:29] <intellectronica> nick tomberger
[04:30] <flacoste> but remember to move the branch from the General queue to your queue when you start the review
[04:30] <barry> flacoste: definitely
[04:30] <kiko> right
[04:30] <flacoste> barry: pre-implementation call weekly status
[04:31] <barry> afaik, this is going pretty well.  i had two buglets i fixed on friday for which i suck (had no pre-impl call), but i'm going to be in hack mode fairly soon and plan to do a lot of them.  all the branches i reviewed for 1.1.6 had them
[04:32] <barry> anybody else have any feedback?
[04:32] <flacoste> did one with tomberger yesterday
[04:32] <barry> flacoste: on the phone?
[04:32] <flacoste> barry: skype
[04:32] <barry> flacoste: cool
[04:32] <flacoste> i think it was definitively worth doing, since it was his second day on the job
[04:33] <bac> i did my first with jtv this week.  it went well.
[04:33] <barry> cool.  seems to be going well.  not sure if we need this agenda item any more
[04:33] <bac> skype to bangkok was flawless
[04:33] <barry> bac: what is that, like 12 hours difference?
[04:33] <bac> yeah but he works euro time, 1pm-9pm local
[04:33] <flacoste> barry: ok, let's remove this from the agenda, we still have it on the general meeting one anyway
[04:34] <barry> bac: cool.  flacoste: +1
[04:34] <flacoste> any other business?
[04:34] <flacoste> bac: what is your mentor status
[04:35] <flacoste> bac: a lot of the reviews you send out have "conditional to agreement by a mentor"
[04:35] <bac> i'm mentored by kiko but he's often too busy so i go out on the open market
[04:35] <bac> i'm a free agent
[04:35] <flacoste> bac: do you think you could find the mentor before sending out the review
[04:36] <kiko> bac, best to find a different mentor at this point :-(
[04:36] <bac> i could try.  sure.
[04:36] <flacoste> the idea being that it is clear to the reviewee who he shall nag for final approval?
[04:36] <bac> so, anyone who is not mentoring someone want to adopt me?
[04:37] <bac> alrighty then
[04:38] <flacoste> bac: i think BjornT is not mentoring anybody
[04:38] <bac> ok, i'll ask him off-line
[04:40] <flacoste> ok, any other business?
[04:40] <flacoste> 5
[04:40] <flacoste> 4
[04:40] <flacoste> 3
[04:40] <flacoste> 2
[04:40] <flacoste> 1
[04:40] <flacoste> MEETING ENDS
[04:40] <flacoste> thanks everyone for attending
[04:40] <barry> thanks flacoste
[05:00] <ubotu> New bug: #121353 in malone "Incorrect count for "projects having bugs" on /projects" [Undecided,Confirmed]  https://launchpad.net/bugs/121353
[05:12] <xdatap> hi everybody
[05:14] <xdatap> i have an issue similar to bug 3446 while importing po file in rosetta. I'm talking with upstream (kde Italian) to fill a bug report on specific package (krita). They ask me how to reproduce that error. Now the question: What rosetta use to validate po file? There's a program on gettext suite to validate in the same way po file for reproduce the problem in local system?
[05:14] <ubotu> Launchpad bug 3446 in knoda "% causes problem in translation strings" [Medium,Rejected]  https://launchpad.net/bugs/3446 - Assigned to Kubuntu Team (kubuntu-team)
[05:20] <xdatap> i have to go, i will post the question on launchpad mailing list... see you
[05:45] <ubotu> New bug: #121360 in launchpad "Notification about impending memberhip expiration may tell users to contact themselves" [Medium,Confirmed]  https://launchpad.net/bugs/121360
[05:56] <ubotu> New bug: #121363 in malone "Order 'most recently closed' on 'Bugtask.id DESC' instead of 'BugTask.id'" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121363
[06:13] <calc> i'm getting integrity errors trying to modify a bug
[06:13] <calc> any ideas about what to do?
[06:45] <BjornT> calc: which bug are you trying to edit? and what are you trying to do?
[06:45] <calc> 15451, talking with kiko about it
[06:46] <calc> i tried to change package, owner, and add a comment
[06:46] <calc> and it keeps giving me integrity error
[06:46] <kiko> yeah
[06:46] <kiko> BjornT, it seems that the OOPS page is failing to render for calc
[06:52] <kiko> matsubara-lunch is aware of this problem, I believe
[06:52] <kiko> the funny thing is that in this case it's reproducible
[06:55] <BjornT> kiko: there might be an open bug about the oops page not rendering for calc.
[06:55] <kiko> there is
[06:55] <kiko> but I'd like to know what the OOPS is :)(
[06:55] <ubotu> New bug: #121378 in launchpad "easy to add mistaken members to a team" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121378
[06:55] <ubotu> New bug: #121380 in launchpad "impossible to remove members from a team" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121380
[06:57] <BjornT> calc: what package are you trying to change, and what are you trying to change it to?
 what exactly were you changing?
 package name, assigned to, and added a comment
[06:58] <BjornT> kiko: i suspect the oops has something to do with the extra "Edgy" task that shouldn't be there without a general Ubuntu task.
[06:58] <calc> package: openoffice.org -> kubuntu-meta assigned: openoffice.org scribblers -> nobody
[06:58] <calc> and i had a comment on the change as well
[06:58] <kiko> BjornT, ah!
[06:58] <kiko> BjornT, the best I have is what tom researched for me: https://devpad.canonical.com/~andrew/paste/file9G09qG.html
[06:59] <BjornT> calc: ah. so the the problem is that there's an "Edgy" line right below "openoffice (upstream)"
[06:59] <calc> BjornT: ah ok
[06:59] <calc> so how do we remove that?
[06:59] <BjornT> if you expand that one, you'll see that it's already assigned to kubuntu-meta, and what's causing problems.
[06:59] <calc> kiko-fud: does devpad use the old password?:
[07:00] <calc> BjornT: ah ok
[07:00] <calc> BjornT: so anyway to remove a tag from a bug?
[07:00] <calc> since edgy is old anyway
[07:00] <BjornT> calc: at the moment you can't remove it, but what you can do is to re-assign it to another package, and reject it.
[07:01] <BjornT> calc: if the bug won't be fixed in edgy, the bug should be rejected in edgy. it's used to keep track where the bug should get fixed, not where the bug exists.
[07:02] <calc> BjornT: ah reassign the task to get rid of it off that bug and reject it afterwards?
[07:02] <calc> so that it doesn't cause the integrity errors anymore?
[07:02] <BjornT> calc: right. i'll see if there's a bug open on fixing this issue.
[07:02] <calc> ok
[07:09] <BjornT> kiko-fud: the oops rendering bug should be bug 58220
[07:09] <ubotu> Launchpad bug 58220 in launchpad "When an error occurs processing a request another oops is recorded because there's no interaction set up." [Medium,Confirmed]  https://launchpad.net/bugs/58220 - Assigned to Diogo Matsubara (matsubara)
[08:24] <Kmos> when LP will be updated with the new status ? it's today.. nothing changed yet
[08:25] <kiko> Kmos, it's not updated yet. wait for tomorrow.
[08:28] <Kmos> kiko: ok :)
[09:02] <kiko> BjornT, wasn't Confirmed renamed to Triaged?
[09:02] <kiko> oh
[09:02] <kiko> no Confirmed is fine
[10:36] <ubotu> New bug: #121418 in Ubuntu "Delete account" [Undecided,Rejected]  https://launchpad.net/bugs/121418
[11:11] <ubotu> New bug: #121434 in malone "Please don't send apport retrace mail on duplicates to subscribers of original bug" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121434
[11:20] <ubotu> New bug: #121436 in launchpad "bug search engine sucks" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121436