=== yofel_ is now known as yofel === 77CAAN8ZB is now known as malev_ [08:17] good morning [09:21] dholbach: hola :) [09:22] hey nigelb [09:22] just updating all the blueprints :) [09:22] Just saw that [09:22] I did some ground work for cleansweep and potential actions that we could do [09:22] nice [09:22] http://people.ubuntu.com/~nigelbabu/operation-cleansweep [09:23] just see how far fetched they are ;) [09:23] vish: re:strace [09:24] I said that because he didn't even bother to copy-paste from the documentation, which worries me :/ [09:25] nigelb: hi.. ooh :s [09:26] thats the reason why I gave -1 overall [09:28] dholbach: Im at work right now but perhaps we can have a chat in around 1.5 to 2 hours [09:28] sounds good to me [09:28] I'll be quite busy until then [09:28] I'd like to get blueprint for cleansweep ready. So much to do :) [09:29] dholbach: hi.. ;) [09:30] hey vish [09:37] * vish had fun time getting lost in Brussels with dholbach :) [09:41] vish: yeah, I had a great time too :) [12:34] dholbach: hey, so you're ready for the planning? [12:51] nigelb: give me a few mins [13:42] nigelb: ok, better now :) [13:42] nigelb: sorry for keeping you waiting [13:45] hey dholbach [13:45] hey BlackZ [13:45] BlackZ: sorry, didn't get to your mail yet [13:46] all a bit hectic trying to catch up with stuff [13:56] dholbach: hi.. for Bug #566996 i had subscribed the main sponsors after i had mentioned it to pitti who mentioned that and since the change is simple enough , with no regressions... [13:56] Malone bug 566996 in humanity-icon-theme "Humanity in KDE does not display volume icons." [Low,Fix committed] https://launchpad.net/bugs/566996 [13:56] * vish was hoping to get that uploaded as sru soonish ;) [13:56] you can just subscribe "ubuntu-sponsors" [13:57] maybe you can prod somebody in #ubuntu-desktop [13:57] righto.. neat [13:57] ty [14:00] hey all [14:01] been checking the patches left but mayority are kinda hard to test, is there going to be another patch day, new commers like me could use some help at times, or just asking here is enough [14:58] effie_jayx, don't hesitate to ask here, there's usually someone who can answer questions [16:05] dholbach: sorry, I lost power. a huge thunderstom hit me [16:05] nigelb: is everything OK now? [16:06] yep. better [16:06] do you want to have a quick chat now? [16:06] yep :) [16:06] awesome [16:06] skype or here on irc? [16:07] anything is fine. [16:07] ok, so about the cleansweep tag [16:07] bdmurray said that it's very costly because it will send a mail out for 2000+ bugs [16:08] yipes [16:08] so including duplicates, multiple subscribers it's probably going to be like 10000 mails, very likely more than that [16:08] ok, so how do we keep track? [16:08] O_O [16:08] I think we should work on the moving target instead [16:08] also: we can't be sure somebody just removes the tag in error [16:09] In that case, dont tag, just subscribe ~ubuntu-reviewers to the subset that we're usually interested it [16:09] s/it/in [16:09] ok, I think that should be fine [16:10] and so we know all the subscribed open bugs are the part of the moving target [16:10] ok, so the code for the "meter" should be fine [16:10] * dholbach has a look at your list of other stuff that needs doing [16:10] can you make the meter show all the subscribed bugs not in any of the bucket? I haven't looked into the code [16:11] already_reviewed_patches = int(ubuntu.searchTasks(has_patch=True, [16:11] status=open_status, [16:11] tags=reviewed_tags, [16:11] tags_combinator='Any')._wadl_resource.representation['total_size']) [16:12] this should be it [16:12] (that's the negation) [16:12] awesome :) [16:13] Also, can you add code to the meter to show the number of bugs left? [16:13] that way I can give uwn a place to access the remaining number (I've talked to them about it at UDS) [16:13] sure [16:14] I'll talk to stephan over the week about documentation [16:14] we'll work on clearing everything by weekend :) [16:14] I'll make a note to do that [16:15] we can rotate blogging responsibilities amoung the team so each person gets to do a weekly report [16:15] sounds good to me [16:15] I'll get to work on osme graphics [16:16] osme graphics? [16:16] um, some ;) [16:16] ah ok :) [16:16] awesome [16:16] this is going to be sweet [16:16] and I've kept daily target at 15 bugs [16:16] its not *very* hard, but its not going to be easy [16:17] we need to keep it on everybody's radar [16:18] yes, perhaps remind everyone to just do one patch per day [16:18] we'll work something out [16:18] :) [16:19] is there anything else that needs clarification? [16:19] the subscription thing...we keep the team subscribed is what I vote for [16:19] I wish persia was here. we were scheudled to argue about it ;) [16:19] haha [16:20] we can start an email conversation [16:20] alright - I'll try to put some more work into this tomorrow [16:20] persia and email - I'd rather not. I'll catch him when he comes on line [16:21] ok :) [16:21] I'll call it a day for today - I need to sort out a few other things still [16:21] I'll get to work on my action items tonight and we'll see what progress we've made tomorrow :) [16:21] have a great day and thanks a bunch! [16:21] awesome [16:22] have a good night :) [16:22] you too [16:22] bye! [16:23] effie_jayx: no, we wont have a patch day [16:23] but if you have a qestion you can ask here. we idle here all the time, someone should get back to you [17:53] nigelb: Hey. Sorry about that: I had some equipment issues. [17:53] persia: oh yay! you're back on :) [17:55] nigelb: So, what's the topic that you've carefully not emailed me about? [17:55] persia: ok, so we have a scheduled argument pending :D [17:55] Do you want to have it tonight, or tomorrow sometime? [17:56] im ok anytime :) [17:57] OK. Let's start now, and if either of us gets tired, we can postpone :) [17:57] haha [17:57] ok, so arguments for subscription [17:57] (a) gives an option for folks to opt out per bug [17:58] (b) someones we have 2 tasks on linux bug and we get sub'd which I manually remove, if we have no unsub option, it would be very difficult to remove those bugs off the work queue [17:58] ok, oppose those, I'll think of a few more in the mean time :D [17:59] (b) is enough to convince me: it indicates that subscription is a useful differentiator for worklist queries. [17:59] aha :) [17:59] (a) seems useless to me, as most folks aren't subscribed to the mailing list. [18:00] not mailing list [18:00] Right. [18:00] I mean opt out of review per bug [18:00] like a responsible core-dev is on it and he feels we don't need to work on it [18:00] My main critique of having a team was that we ought come up with a reason why a team was more useful than tag management. [18:00] the main usefulness is (b0 [18:00] (b) [18:00] Right. [18:01] * nigelb is surprised we ended early. [18:01] Also, my client is giving you a green color, used to be red. [18:01] Now, to question that: is subscription to achieve that goal better than a tag-based workflow? [18:01] Funny. My interaction with my client changed, but the actual IRC client hasn't been modified in weeks. [18:03] tag based workflow is good, but not perfect. [18:03] We have a lot of corner cases where bug is at user level but fix is at kernel level. [18:03] Can't really modify the script to ignore them, need manual intervention [18:04] well, not a lot, but around 5 or 6 at least [18:05] so, if we didn't have subscription, the script would just add tags. Removing a tag can be done by anyone. Unsubscribing a team is a restricted activity. [18:05] So the actual work is *exactly* the same: it's just a decision whether the mechanism is unsubscribe or remove a tag. [18:06] That said, script implementaiton is easier if it's subscription-based :) [18:07] I like that idea. That way there would be an identity around the team :) [18:07] Perhaps we should go in that direction. Especially since I have a task assigned to create an identiy around the team [18:07] See, that's the reason I suggested consideration of alternate methods. [18:08] I think that associating identity with the reviewers is a bad thing: I think we'll get more reviewers with less conflict if reviewing is an activity engaged in by other groups that have identity (various development teams, bug control, etc.) [18:08] So, we unsubscribe the team if the patch tag is changed to any of the patch* tags [18:09] ok, I'm confused. [18:09] So we promote review as an activity? [18:09] I think that would result in faster growth and sustainable size. [18:10] Because otherwise people may ask "Are you a bug triager or a patch reviewer?". I'd like to avoid that question. I don't think any of the answers help us. [18:11] So, we don't go into the subscription issue because that would mean not being in the team would block contribution? [18:12] Unless we believe there is sufficient value in the subscription to make that cost affordable :) [18:12] (b) above is a very strong argument. [18:13] Someday, you'll talk in simple english. [18:13] Half the time I go 'ok, what the heck is he trying to say?' [18:15] So, there is a cost to 1) having an identity for the team, rather than it being an activity, and 2) using subscription because this is a restricted activity. [18:15] There are benefits to each of identity and use of subscription for workflow management. [18:15] I'd rather have it an activity. Then we can say, folks, review one patch per day. [18:15] The benefits need to outweigh the costs in order for either of those choices to be the correct choice. [18:16] That was what I was thinking :) [18:16] And people would be happy to. Being in team, etc would irritate devs who just want to help for one or 2 bugs [18:17] Our progress needs to be onnly 12 bugs per day or more, we should be well on way to target. I've kept target at 15 bugs per day for now. [18:22] So, we'll make the final call as no identity for team but as activity? [18:22] 15 seems like a good number. high enough that we can miss a few days, but low enough that most people won't be bothered to do the math to notice it's wrong. [18:22] That's my preference, if you're comfortable with that model. [18:23] I already planned stuff around it :) [18:23] Note that I think patch review is *important*, but I just don't think we want folk who self-identify *as* reviewers, but instead encourage devs & triagers to review. [18:23] Like sponsors right? [18:23] My experience with the dev/triager identity differentiation is not positive: in the beginning, devs triaged, and triagers were proto-devs, but now I'm unsure if many devs even look at bugs at all [18:24] Except for package set folks [18:25] Hrm? Without exception. I know of some packageset folks who work within a packageset, but don't use LP as an input source for things to do. [18:25] I see the Desktop Team very active on bugs though [18:26] Yes. Many developers are very active in bugs. [18:26] Just not all of them. [18:27] That way. Yeah. [18:27] I don't know if this is related to the separation of identity, or just a result of the volume of work to be done, but I suspect it to be a combination of the two. [18:27] I think its both. I haven't triaged bugs for long. Its mostly lack of time. [18:27] When I get time, I only triage patches or look for bugs to fix. [18:28] And I'm not a dev yet, so I can imagine what the devs go through [18:28] Makes sense. [18:28] Well, some of them *do* still triage, which is a good thing. [18:28] What I do get around to is helping other triagers in -bugs when they're stuck. [18:29] Anyway, it feels to me like we both have had separate paths to similar conclusions since we scheduled our discussion, and so had already reached consensus :) [18:29] hehe [18:30] Have a good night, and good luck. From the bits I heard here and there at UDS, it sounds like you've signed up for a good bundle of work, but the results ought be fantastic. [18:30] Yes, and bundle is actually an understatement. [18:30] heh [18:31] I'm going to withdraw from a few teams this cycle though. Some stuff just needs to go. [18:33] I know how that is :) [18:33] :) === yofel_ is now known as yofel