sooooo, as the topic says: Feel free to fire up gobby and connect to mafiasi.de:6522. we can take notes in real time and see the agenda and everything So the agenda is at http://live.gnome.org/Bugsquad/Meetings/20090905 Let's start the meeting :) * chromy (~chromy@chello089173070061.chello.sk) ha abandonado #bugs-meet * chromy (~chromy@chello089173070061.chello.sk) ha entrado en #bugs-meet Welcome and thanks for attending :) Let's hope we can catch up the lost hour ;-) * Muelli da OP a chromy So we have decided to handle old bugs which haven't been touched in ages. There should be a new stock response but we don't have stock responses at all, so we probably have to defer syncing the new stock response to the wiki. Do we have an open bug, requesting stock answers back? http://bugzilla.gnome.org/buglist.cgi?quicksearch=stock&product=bugzilla.gnome.org doesn't show anything. So we need someone to open a bug and let bug 590840 and 591222 depend on it :o) I can do that nice * rego (~rego@186.Red-79-146-211.dynamicIP.rima-tde.net) ha entrado en #bugs-meet * rego (~rego@186.Red-79-146-211.dynamicIP.rima-tde.net) ha abandonado #bugs-meet Actually, we can sync the stockresponse to the wiki anyway. I mean we need to do that sooner or later anyway.. *thinking* I'll do that :) nice ;) ACTION: jjardon to open a bug requesting stockresponses ACTION: Muelli to sync stock response to TriageGuide and StockResponses * cosimoc (~cosimoc@jalfrezi.collabora.co.uk) ha entrado en #bugs-meet * Muelli da OP a cosimoc hi guys Hm. I wonder how "needinfo-trynewversion" came onto the agenda ;-) hey cosimoc :) ah, yeah, sure. Once you hit a NEEDINFO bug with that keyword set, you can automatically close it. hello cosimoc cosimoc: agenda on gobby server or in the wiki: http://live.gnome.org/Bugsquad/Meetings/20090905 :) anything else on the old-nottouched bugs? chromy, cosimoc, jjardon, lakhil? nope .. i am using comment which andre suggested in last meeting so that reporter will be aware of 6 weeks deadline lakhil: so yuo copy&paste that stock answer from the wiki page? Muelli, so the item you're discussing is old untouched bugs now? from tomboy :) cosimoc: yep. one could see that in the gobby session ;-) * cosimoc ignores what gobby is k. then there's nothing else to add, I guess. Muelli, for close needinfo bugs I simply search for NEEDINFO bugs without activity for 6 weeks, is the tag really necessary? hm. Muelli, pardon me if you already discussed this, but what about bugs that are already in bugzilla and are UNCONFIRMED and without comments since more than 6 months right now? will they be closed? well jjardon. I don't really know what "activty" in bugzilla speak is. hm cosimoc. not 6 months but 1 year: http://live.gnome.org/Bugsquad/Meetings/20090803 Bugs with 1 year without any activity (not enhacement bugs) -> set NEEDINFO state -> 6 weeks without response -> close as INCOMPLETE jjardon: So I don't think the tag is really necessary. I though it's convenient to search for that tag and to be sure that this is an old-untouched" NEEDINFO which can be closed. please don't forget to update version correctly if anyone confirms the bug on later / recent version So, I think I'll mention that tag in the wiki and we'll see if it's a good thing or not. Muelli, ok, that's probably fair, but I wonder if it would be a good thing for the triager to try reproduce the bug before setting NEEDINFO yeah, sure cosimoc. that should be the case. cool But I feel that this the minority of bugreports are easily reproducible. s/this// lakhil, yeah, there is a warning in the stock response: http://bugzilla.gnome.org/show_bug.cgi?id=591222 so. anything else on old-untouched bugs? jjardon: what i meant to say that most of the times reporter forgets to change version appropriately so we should make sure that we upgrade version correctly lakhil, yeah, you are totally rigth Muelli, not for me Next point: "Make more clear the triager workflow". jjardon: Can you elaborate? * fabio (~fabio@200-50-107-130.static.tie.cl) ha entrado en #bugs-meet Muelli, well, I think that may help a "graphical" workflow for new triagers hey fabio :) hi Muelli :-) So you think we should have that diagram in the TriageGuide somewhere? (is more easy see a diagram than read a lot info) Muelli, yes jjardon: the good news is that it's already linked: http://live.gnome.org/Bugsquad/TriageGuide :) Maybe we can have a real image, not just the link... jjardon: can you upload the sources of that image to the wiki? Muelli, sure awesome. So jjardon, do you think it's enough if we have that image as an actual image built in to the TriageGuide? ACTION: jjardon to upload the Triager_Diagram Sources to the wiki * Muelli da OP a fabio Muelli, yes ACTION: jjardon to fix typo in http://live.gnome.org/Bugsquad/TriageGuide?action=AttachFile&do=view&target=Diagram_triagers.png: "Assigned" :P already fixed ;) nice sources uploaded too do we want to metnion anything about when bug should be moved to new and by whom ? And we shouldn't have the hardcoded GNOME 2.22 reference. Probably something more generic like "version older than two releases". Muelli, done yeah, well lakhil. It probably depends on what we want to achieve with that diagram. Putting too much information in it makes it unreadable. But I generally agree in putting that information into that image as we mentioned point 1 and 2 below diagram .. we can something for New also as not all the bugs should be moved to new who gets needed info from reporter yeah, maybe a good idea. So we probably need something like "Reproducible by Triage or enough duplicates?" to the transition from UNCONFIRMED to NEW..? sounds good lakhil: do you want to update that image with jjardon? sure Muelli, that was discussed in previous meeting oh, really. *blush* a long discussion http://live.gnome.org/Bugsquad/Meetings/20090803#head-12cb265bd2df93b7eeb277ffb617a22e697be82f yeah, well. But this is not necessarly about when to use NEW but how to enhance to diagram ;-) jjardon: we don't want to change meaning but we should put some guide line so lakhil, do you want to propose changes to that image until the next meeting or so? :) * andre (~andre@g1.blanicka25.net) ha entrado en #bugs-meet * Muelli da OP a andre i will try to come up so we can discuss next time I'd like to use NEW for triagued bugs or with a lot of dupes, I think that is a good idea ACTION: lakhil to enhance the diagram by some rough guidelines on, e.g., when to set to NEW So, anything else on the Diagram or the TriageGuide? andre, chromy, cosimoc, fabio, jjardon, lakhil? nope no k. Let's jump to the next point then :) "3. Set up a bot to notify us about new bugs in #bugs" jjardon: Why do you think it'd be a good thing? :) In fact, I'm against it, because we have way too much traffic on the bugzilla ;-) Muelli, I don't think that It's a good idea anymore ;). Ad Andre said, we have #bzbot but maybe a mention in bugsquad pages would be good jjardon: :) Would be interesting to know why you thought it's a good thing in first place though. yeah, definitely. We shuold document our infrastructure :) where would that actually fit best? in http://live.gnome.org/Bugsquad/ "How can I help?" section ? So, there is a common place to mention two bugsquad channels: #bugs and #bzbot I'd say under "Useful resources - Bugzilla tools". Like "bugbot in #bzbot who notices every change to the bugzil;a" or so. uh, the #bugs channel should be mentioned along with the mailinglist under Useful resources Muelli, +1 and +1 from me okay, I'll take that job :) ACTION: Muelli to mention #bzbot and #bugs in the BugSquad page. i like too bugbot in #bzbot so, anything else on bugbot or the documentation on the BugSquad page? Muelli, yeah Simple duplicate finder link is broken :) (and maybe more with the change to new bugzilla) uh. yeah. crap http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates needs an update So, we can point Simple duplicate finder to http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates instead http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi and update http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates http://live.gnome.org/Bugsquad/YourOwnBugs has a deadlink to http://bugzilla.gnome.org/describeuser.cgi but we definitly want that page back.. Andre, do you know whether we have an open bug for that? don't know of one sounds good jjardon. andre: care to create one? :) Muelli, anotate me to update http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates ;) well, i'm in "no more work please" mode ;-) hehe http://bugzilla.gnome.org/show_bug.cgi?id=591936 *yay* so jjardon, did I get you right, that your idea was to redirect from the s-d-f page to FindingDuplicates? Muelli, yes like from http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi tol.g.o/FindingDuplicates ? yes k. I like that idea. Although I like the old s-d-f :'( It showed me that functions it found which I found quite handy some times. any objections against redirecting from the old s-d-f to FindingDuplicates? when we click on traces, it shows bugs which have similar traces so we don't have plan to add s-d-f in the bugs, right ? yeah. s-d-f is gone in favour of the StackTraceParser... ah..k so jjardon. Do you want to request that redirection? yeah awesome. luckily updating FindingDuplicates isn't that hard because it doens't mention s-d-f a lot. anyone willing to update that page? Muelli, redirection done uh, how did you do that? I though it involves asking sysadmins... okay, we still need someone explaining in http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates how to find duplicates ;-) Muelli, I've only modified the link from http://live.gnome.org/Bugsquad ah jjardon. So I probably got you wrong. Muelli, ok my fault, I did not understand well waht you want. I see now. But I think is better to fix al the wiki links than and point them to http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates than to make a redirection from s-d-f page to FindingDuplicates yep, you're right jjardon. http://live.gnome.org/Bugsquad/TriageGuide?action=fullsearch&context=180&value=s-d-f&fullsearch=Text shows two pages. http://live.gnome.org/Bugsquad/TriageGuide?action=fullsearch&context=180&value=dup-finder&fullsearch=Text shows three. * Muelli gets himself a coffee Muelli, I'll fix them ;) awesome :) Still need anyone to update FindingDuplicates to mention the new s-d-f replacement * Notificación: tbf se ha conectado (GimpNet). okay, Ill do that... :P ACTION: Muelli to update FindingDuplicates to mention the new s-d-f replacement okay, still anything on documenation? nope k. let's move on to the next point then... "4. Cleaning BugStatus". jjardon: I think this was your point, can you elaborate? forget it, I think now that is not a good idea ;) just for the record: ACTION: jjardon to fix pages shown up http://live.gnome.org/Bugsquad/TriageGuide?action=fullsearch&context=180&value=dup-finder&fullsearch=Text and http://live.gnome.org/Bugsquad/TriageGuide?action=fullsearch&context=180&value=s-d-f&fullsearch=Text Muelli, already done okay. anybody else wants to take that point ("Cleaning BugStatus")? doesn't seem to be the case :o) Muelli, Can you take a look at http://live.gnome.org/Bugsquad/AutoReject ? when you upgrade FindingDuplicates page I think that they are related k jjardon. let's talk about that later on :) So, I propose to care about the next point: "5. Add ApplicationSpecificInstructions to the TriageGuide"... jjardon, I think that was your point, right? Muelli, nope, I think is a Rosana request :) OKay, so if the idea is to integrate ProductSpecificGuidelines into TriageGuide, I'm against it, because it's way too much. Muelli, the thing is move GettingTraces into TriageGuide pages, I think ah, now I see it. hm. (+1 from me) * lakhil (~Administr@117.192.0.244) ha abandonado #bugs-meet currently, the TriageGuide reads "Mark them NEEDINFO if they don't have a stack trace, and ask the reporter to get a stack trace (refer them to http://live.gnome.org/GettingTraces for more information).". I think it's pretty good, one could link to GettingTraces/ApplicationSpecificInstructions though. I don't know, I mean we have plenty of ApplicationSpecificInstructions which would blow up the triage guide page. don't you think so jjardon? Muelli, but getting traces is not a job of bugsquad team? ;) Maybe move the pages to Bugsquad/? actually, it's more for the bug reporter than for the bugsquad. Except a triager can reproduce the bug.. ;-) you have to move all the subpages manually ? *shrug* dunno. But yeah, the GettingTraces could be moved to bugsquad namespace. But there's no real need for it too. If yes, I think is a lot of work maybe for the next meeting ? Maybe. We can at least discuss if it's necessary to move or not :) But still, was the proposal to move GettingTraces/ApplicationSpecificInstructions into TriageGuide? And were you in favor of that jjardon? ;-) I thik that It's necessary, but It's a lot of work if you have to move al the subpages manually ;) but then I didn't get it. jjardon: can you rephrase the proposal? I'm in favor to move all GettingTraces/ApplicationSpecificInstructions pages to TriageGuide Like copying the contents into the TriageGuide page so that it gets really huge? and actually it's not really a Triage related thing as we might ask the reporter to have a look at the GettingTraces/ApplicationSpecificInstructions for installing the necessary symbols. no, I meant move the pages to Bugsquad/TriageGuide namespace, so you will have Bugsquad/TriageGuide/GettingTraces/ApplicationSpecificInstructions ah. okay. Do you think that was the intention of the point on the agenda? "Add ApplicationSpecificInstructions to the TriageGuide"? Muelli, yes, I think but maybe would be better ask Rosana ;) okay. Well. I don't really think its worth the hassle. I mean technically, we are in charge to maintain those pages and thus it should be in our namespace. But I don't have a really compelling reason to actually move the pages ;-) Plus, we have to update the backreferences like the stockanswers and everything So, it's a -1 from me Muelli, ok, you convinced me ;) okay, next point then? andre, chromy, fabio, jjardon? :-) "6. Refactor ProductSpecificGuidelines" - There are acutally many rules to obey. kind of a hassle. Muelli, I vote to remove that page :) hm jjardon. And then simply delete the information in that page? Muelli, yes, or mark it as deprecated and start a new page hm. I think it's necessary to have ModuleSpecificRules though. I mean each module might have it's own informatino it need to fix a bug.. So I'm definitely not in favor of simply deleting this information But actually I'm not convinced, that collecting ModuleSpecificTriageGuidelines under the BugSquad namespace. Instead, I think in the modules namespace would be a better place. But I'm not aware of any method of automatically aggregating subpages into one different page. Maybe a solution is to have the modules naming their TiageGuide pages like "TriageGuide" and just refer to a search for pages with that name... mmm, I think is better have all the info in one place, and think that there are modules that doesn't have a page in gnome wiki What do you think about rename http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines to http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelinesOld and start a new ProductSpecificGuidelines page ? My reasoning is, that the rules belong to a module. And thus the rules belong to the modules namespace. Of course I want to have a list of all guidelines that's why I'm looking for a method to actually aggregating all of them into a single page. jjardon: what would you do different then? Muelli, I think is more easy start a new page than cleaning the actual page (we can send a mail to add specific rules in the new page if they want) mail to mainteiners hm. but I mean, what would be different in that new page? I'm totally in favour of making reading the ProductGuidelines easier, but I have no clue how it could be done? I would totally recreate that page the way it currently is.. mmm, I get you So I actually don't think that we can really improve the number of rules. But we can probably display them better. Maybe automatically display a link to the rules in the bugzilla. I think that we should encourage devels to follow the general rules, and in very specific cases make a specific rule yeah sure. Is there any rule on http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines that you think is wrong or too general? Control center: Any problems related to versions before 2.4.x can be closed as WONTFIX that one maybe "# If possible get a backtrace from the user with all thread backtraces (i.e. using 'bt thread apply all' instead of 'bt' in GDB). " for example yeah, it'd probably be OBSOLETE anyway. ekiga: It is important to find out how the user installed it, whether from a distribution or from source code. and a lot more hm. So we shuold probably clean them up... or start a new page and send a mail to modules maintainers to add your own (very specific) rules hm. (or send a mail to gnome-desktop-devel) well, could be an option as well. I'm wondering what's the actual problem with having one or two unneccessary rules per module? I mean ideally, a triager looks up the rules for a module and finds 6 at maximum (epiphany). Have 1 or 2 redundant rules is not that bad, is it? maybe, but, how Can we know that they are still valid (some rules are pretty old)? hm. which one? I mean, in general you have to assume that the rules are valid and that maintainers come around and clean old and unneeded rules. We could probably ask the maintainers to clean up their rules in http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines. Muelli, +1 and if not response, remove the specific rules what do you think? So we need a text for a mail to be send to all maintainers or maybe d-d-l. yaeh well. I don't have a specific rules I want to get rid of :) But I think reminding maintainers of having a look at their rules is good. or we can file bugs for that, so we now if It's already fixed or not jjardon: you mean file a bug for each rule we think is unneccesary? file a bug for each module that It is in http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines To say the mainteiner to update the info And what would be the bug about? Like "Please review your rules"? yes oh well. I guess this is a bit too much ;-) We shouldn't file bugs if we don't know whether there's an issue :P But yeah, maybe I'm just too conservative ;) we can have a tracker bug to all of these bugs to track the progress Muelli, ;) I think writing a mail is fair enough. But yeah, if you want to file bugs, do that. ok, Someone to write the generic and polite bug/email message ? ;) yes ^^ I probably can do that... ACTION: Muelli to write a mail to be send to maintainers or d-d-l to ask for reviewing their rules. Muelli, great Can we actually file bugs against ourselves? That would help to keep track of the assigned tasks Muelli, good idea general - General unclassified bugs where THE REPORTER IS RESPONSIBLE FOR FIXING any bugs they report (or is at least in charge of personally contacting and directing all possibly relevant people). Please avoid using this category unless you are a Gnome developer. Bugs in this category are not typically read. NOT FOR OPENOFFICE.ORG OR ABIWORD: they do not live on gnome-bugzilla (see http://live.gn yep, I'm using general... maybe we can ask for a bugsquad module ? yep, I mean asking is the least thing we can do :) might be a good idea... *thinking* maybe andre knows why we don't have such a thing already..? hm. dunno.. do you think it'd be a good think jjardon? I think that would be a good think, yes. So we can see open issues about meeting/actions much faster and a mail notify us when a actions is done, we can do some actions depends on others ... hm. indeed, we can have a new category in the bugzilla: teams and encourage other teams to use the bugzilla too yeah, well. bugzilla is not the best product to track tasks. We also have a request tracker which performs better in tracking tasks. But I think using the bugzilla as much as possible is good because the less infrastructure we have to care about, the better. I think the same where is the request tracker? www.gnome.org/rt3 I guess. https://www.gnome.org/rt3/ So are you wililng to come up with a text for bugmaster, asking for a module? Or maybe directly send that CCing bugsquad... ok ACTION: jjardon to ask bugmaster/sysadmin to create a new "bugsquad" module in bugzilla. what is the mail of the bugmaster/sysadmin ? bugmaster@gnome.org I guess ok wondering who that acutally is.. yep bugmaster@gnome.org Please file a ticket in bugzilla.gnome.org against bugzilla.gnome.org if you want a new module please avoid sending emails. alright. I'm filing later on... If jjardon is not faster :-) Muelli, send you the mail, your english is probably better ;) k Muelli, from http://live.gnome.org/RoadMap : "Switch from RT3 to Bugzilla" :) http://live.gnome.org/RoadMap#head-d1542b70c92facdb35b11856245efc7bb42a2e8d-2 uh. just slightly good idea. We had a conversation on membership-team regarding whether to use bugzilla. Turns out, rt3 fits our workflow much better. Muelli, oh, ok, I dont know rt3 tool anyway, I'm running out of power. We either have a break, or defer the last 6 (sic!) points to the next meeting. Or you guys keep rocking while I'm having a coffeebreak... I think is enough ;) heh but BugsquadGoals is a good point to discuss later ;) yeah, well. Thank you guys for being productive again :-) I'm closing this meeting then :) I think I'm going to wrap everything up, write a log and send that to bugsquad-l then. great, thank you very much for your work Muelli ;) I think the gobby was good. Though one could probably make more use of it I for one have started to take my nodes and prepare my statements there. Others could see them and actually prepare themselves as well :-)