1 <Muelli> 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 2 <Muelli> So the agenda is at http://live.gnome.org/Bugsquad/Meetings/20090905 3 <Muelli> Let's start the meeting :) 4 * chromy (~email@example.com) ha abandonado #bugs-meet 5 * chromy (~firstname.lastname@example.org) ha entrado en #bugs-meet 6 <Muelli> Welcome and thanks for attending :) Let's hope we can catch up the lost hour ;-) 7 * Muelli da OP a chromy 8 <Muelli> So we have decided to handle old bugs which haven't been touched in ages. 9 <Muelli> 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. 10 <Muelli> Do we have an open bug, requesting stock answers back? 11 <Muelli> http://bugzilla.gnome.org/buglist.cgi?quicksearch=stock&product=bugzilla.gnome.org doesn't show anything. 12 <Muelli> So we need someone to open a bug and let bug 590840 and 591222 depend on it :o) 13 <jjardon> I can do that 14 <Muelli> nice 15 * rego (~rego@186.Red-79-146-211.dynamicIP.rima-tde.net) ha entrado en #bugs-meet 16 * rego (~rego@186.Red-79-146-211.dynamicIP.rima-tde.net) ha abandonado #bugs-meet 17 <Muelli> Actually, we can sync the stockresponse to the wiki anyway. I mean we need to do that sooner or later anyway.. *thinking* 18 <Muelli> I'll do that :) 19 <jjardon> nice ;) 20 <Muelli> ACTION: jjardon to open a bug requesting stockresponses 21 <Muelli> ACTION: Muelli to sync stock response to TriageGuide and StockResponses 22 * cosimoc (~email@example.com) ha entrado en #bugs-meet 23 * Muelli da OP a cosimoc 24 <cosimoc> hi guys 25 <Muelli> Hm. I wonder how "needinfo-trynewversion" came onto the agenda ;-) 26 <Muelli> hey cosimoc :) 27 <Muelli> ah, yeah, sure. Once you hit a NEEDINFO bug with that keyword set, you can automatically close it. 28 <jjardon> hello cosimoc 29 <Muelli> cosimoc: agenda on gobby server or in the wiki: http://live.gnome.org/Bugsquad/Meetings/20090905 :) 30 <Muelli> anything else on the old-nottouched bugs? 31 <Muelli> chromy, cosimoc, jjardon, lakhil? 32 <lakhil> nope .. i am using comment which andre suggested in last meeting 33 <lakhil> so that reporter will be aware of 6 weeks deadline 34 <Muelli> lakhil: so yuo copy&paste that stock answer from the wiki page? 35 <cosimoc> Muelli, so the item you're discussing is old untouched bugs now? 36 <lakhil> from tomboy :) 37 <Muelli> cosimoc: yep. one could see that in the gobby session ;-) 38 * cosimoc ignores what gobby is 39 <Muelli> k. then there's nothing else to add, I guess. 40 <jjardon> Muelli, for close needinfo bugs I simply search for NEEDINFO bugs without activity for 6 weeks, is the tag really necessary? 41 <Muelli> hm. 42 <cosimoc> 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? 43 <Muelli> well jjardon. I don't really know what "activty" in bugzilla speak is. 44 <Muelli> hm cosimoc. not 6 months but 1 year: 45 <Muelli> http://live.gnome.org/Bugsquad/Meetings/20090803 46 <Muelli> Bugs with 1 year without any activity (not enhacement bugs) -> set NEEDINFO state -> 6 weeks without response -> close as INCOMPLETE 47 <Muelli> 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. 48 <lakhil> please don't forget to update version correctly if anyone confirms the bug on later / recent version 49 <Muelli> So, I think I'll mention that tag in the wiki and we'll see if it's a good thing or not. 50 <cosimoc> 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 51 <Muelli> yeah, sure cosimoc. that should be the case. 52 <cosimoc> cool 53 <Muelli> But I feel that this the minority of bugreports are easily reproducible. 54 <Muelli> s/this// 55 <jjardon> lakhil, yeah, there is a warning in the stock response: http://bugzilla.gnome.org/show_bug.cgi?id=591222 56 <Muelli> so. anything else on old-untouched bugs? 57 <lakhil> jjardon: what i meant to say that most of the times reporter forgets to change version appropriately 58 <lakhil> so we should make sure that we upgrade version correctly 59 <jjardon> lakhil, yeah, you are totally rigth 60 <jjardon> Muelli, not for me 61 <Muelli> Next point: "Make more clear the triager workflow". jjardon: Can you elaborate? 62 * fabio (~firstname.lastname@example.org) ha entrado en #bugs-meet 63 <jjardon> Muelli, well, I think that may help a "graphical" workflow for new triagers 64 <Muelli> hey fabio :) 65 <fabio> hi Muelli :-) 66 <Muelli> So you think we should have that diagram in the TriageGuide somewhere? 67 <jjardon> (is more easy see a diagram than read a lot info) 68 <jjardon> Muelli, yes 69 <Muelli> 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... 70 <Muelli> jjardon: can you upload the sources of that image to the wiki? 71 <jjardon> Muelli, sure 72 <Muelli> awesome. So jjardon, do you think it's enough if we have that image as an actual image built in to the TriageGuide? 73 <Muelli> ACTION: jjardon to upload the Triager_Diagram Sources to the wiki 74 * Muelli da OP a fabio 75 <jjardon> Muelli, yes 76 <Muelli> ACTION: jjardon to fix typo in http://live.gnome.org/Bugsquad/TriageGuide?action=AttachFile&do=view&target=Diagram_triagers.png: "Assigned" 77 <Muelli> :P 78 <jjardon> already fixed ;) 79 <Muelli> nice 80 <jjardon> sources uploaded too 81 <lakhil> do we want to metnion anything about when bug should be moved to new and by whom ? 82 <Muelli> And we shouldn't have the hardcoded GNOME 2.22 reference. Probably something more generic like "version older than two releases". 83 <jjardon> Muelli, done 84 <Muelli> yeah, well lakhil. It probably depends on what we want to achieve with that diagram. 85 <Muelli> Putting too much information in it makes it unreadable. But I generally agree in putting that information into that image 86 <lakhil> as we mentioned point 1 and 2 below diagram .. we can something for New also 87 <lakhil> as not all the bugs should be moved to new who gets needed info from reporter 88 <Muelli> yeah, maybe a good idea. So we probably need something like "Reproducible by Triage or enough duplicates?" to the transition from UNCONFIRMED to NEW..? 89 <lakhil> sounds good 90 <Muelli> lakhil: do you want to update that image with jjardon? 91 <lakhil> sure 92 <jjardon> Muelli, that was discussed in previous meeting 93 <Muelli> oh, really. *blush* 94 <lakhil> a long discussion 95 <jjardon> http://live.gnome.org/Bugsquad/Meetings/20090803#head-12cb265bd2df93b7eeb277ffb617a22e697be82f 96 <Muelli> yeah, well. But this is not necessarly about when to use NEW but how to enhance to diagram ;-) 97 <lakhil> jjardon: we don't want to change meaning but we should put some guide line 98 <Muelli> so lakhil, do you want to propose changes to that image until the next meeting or so? :) 99 * andre (~email@example.com) ha entrado en #bugs-meet 100 * Muelli da OP a andre 101 <lakhil> i will try to come up so we can discuss next time 102 <jjardon> I'd like to use NEW for triagued bugs or with a lot of dupes, I think that is a good idea 103 <Muelli> ACTION: lakhil to enhance the diagram by some rough guidelines on, e.g., when to set to NEW 104 <Muelli> So, anything else on the Diagram or the TriageGuide? andre, chromy, cosimoc, fabio, jjardon, lakhil? 105 <jjardon> nope 106 <fabio> no 107 <Muelli> k. Let's jump to the next point then :) 108 <Muelli> "3. Set up a bot to notify us about new bugs in #bugs" jjardon: Why do you think it'd be a good thing? :) 109 <Muelli> In fact, I'm against it, because we have way too much traffic on the bugzilla ;-) 110 <jjardon> Muelli, I don't think that It's a good idea anymore ;). Ad Andre said, we have #bzbot 111 <jjardon> but maybe a mention in bugsquad pages would be good 112 <Muelli> jjardon: :) Would be interesting to know why you thought it's a good thing in first place though. 113 <Muelli> yeah, definitely. We shuold document our infrastructure :) 114 <Muelli> where would that actually fit best? 115 <jjardon> in http://live.gnome.org/Bugsquad/ "How can I help?" section ? 116 <jjardon> So, there is a common place to mention two bugsquad channels: #bugs and #bzbot 117 <Muelli> I'd say under "Useful resources - Bugzilla tools". Like "bugbot in #bzbot who notices every change to the bugzil;a" or so. 118 <Muelli> uh, the #bugs channel should be mentioned along with the mailinglist under Useful resources 119 <jjardon> Muelli, +1 and +1 from me 120 <Muelli> okay, I'll take that job :) 121 <Muelli> ACTION: Muelli to mention #bzbot and #bugs in the BugSquad page. 122 <fabio> i like too bugbot in #bzbot 123 <Muelli> so, anything else on bugbot or the documentation on the BugSquad page? 124 <jjardon> Muelli, yeah 125 <jjardon> Simple duplicate finder link is broken 126 <Muelli> :) 127 <jjardon> (and maybe more with the change to new bugzilla) 128 <Muelli> uh. yeah. 129 <Muelli> crap 130 <Muelli> http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates needs an update 131 <jjardon> 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 132 <jjardon> and update http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates 133 <Muelli> 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? 134 <andre> don't know of one 135 <Muelli> sounds good jjardon. 136 <Muelli> andre: care to create one? :) 137 <jjardon> Muelli, anotate me to update http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates ;) 138 <andre> well, i'm in "no more work please" mode ;-) 139 <Muelli> hehe 140 <andre> http://bugzilla.gnome.org/show_bug.cgi?id=591936 141 <Muelli> *yay* 142 <Muelli> so jjardon, did I get you right, that your idea was to redirect from the s-d-f page to FindingDuplicates? 143 <jjardon> Muelli, yes 144 <Muelli> like from http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi tol.g.o/FindingDuplicates ? 145 <jjardon> yes 146 <Muelli> k. I like that idea. 147 <Muelli> Although I like the old s-d-f :'( It showed me that functions it found which I found quite handy some times. 148 <Muelli> any objections against redirecting from the old s-d-f to FindingDuplicates? 149 <lakhil> when we click on traces, it shows bugs which have similar traces 150 <lakhil> so we don't have plan to add s-d-f in the bugs, right ? 151 <Muelli> yeah. s-d-f is gone in favour of the StackTraceParser... 152 <lakhil> ah..k 153 <Muelli> so jjardon. Do you want to request that redirection? 154 <jjardon> yeah 155 <Muelli> awesome. 156 <Muelli> luckily updating FindingDuplicates isn't that hard because it doens't mention s-d-f a lot. 157 <Muelli> anyone willing to update that page? 158 <jjardon> Muelli, redirection done 159 <Muelli> uh, how did you do that? I though it involves asking sysadmins... 160 <Muelli> okay, we still need someone explaining in http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates how to find duplicates ;-) 161 <jjardon> Muelli, I've only modified the link from http://live.gnome.org/Bugsquad 162 <Muelli> ah jjardon. So I probably got you wrong. 163 <jjardon> 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 164 <Muelli> yep, you're right jjardon. 165 <Muelli> http://live.gnome.org/Bugsquad/TriageGuide?action=fullsearch&context=180&value=s-d-f&fullsearch=Text shows two pages. 166 <Muelli> http://live.gnome.org/Bugsquad/TriageGuide?action=fullsearch&context=180&value=dup-finder&fullsearch=Text shows three. 167 * Muelli gets himself a coffee 168 <jjardon> Muelli, I'll fix them ;) 169 <Muelli> awesome :) 170 <Muelli> Still need anyone to update FindingDuplicates to mention the new s-d-f replacement 171 * Notificación: tbf se ha conectado (GimpNet). 172 <Muelli> okay, Ill do that... :P 173 <Muelli> ACTION: Muelli to update FindingDuplicates to mention the new s-d-f replacement 174 <Muelli> okay, still anything on documenation? 175 <jjardon> nope 176 <Muelli> k. let's move on to the next point then... 177 <Muelli> "4. Cleaning BugStatus". jjardon: I think this was your point, can you elaborate? 178 <jjardon> forget it, I think now that is not a good idea ;) 179 <Muelli> just for the record: 180 <Muelli> 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 181 <jjardon> Muelli, already done 182 <Muelli> okay. anybody else wants to take that point ("Cleaning BugStatus")? 183 <Muelli> doesn't seem to be the case :o) 184 <jjardon> Muelli, Can you take a look at http://live.gnome.org/Bugsquad/AutoReject ? 185 <jjardon> when you upgrade FindingDuplicates page 186 <jjardon> I think that they are related 187 <Muelli> k jjardon. let's talk about that later on :) 188 <Muelli> So, I propose to care about the next point: "5. Add ApplicationSpecificInstructions to the TriageGuide"... jjardon, I think that was your point, right? 189 <jjardon> Muelli, nope, I think is a Rosana request 190 <Muelli> :) OKay, so if the idea is to integrate ProductSpecificGuidelines into TriageGuide, I'm against it, because it's way too much. 191 <jjardon> Muelli, the thing is move GettingTraces into TriageGuide pages, I think 192 <Muelli> ah, now I see it. 193 <Muelli> hm. 194 <jjardon> (+1 from me) 195 * lakhil (~Administr@126.96.36.199) ha abandonado #bugs-meet 196 <Muelli> 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. 197 <Muelli> I don't know, I mean we have plenty of ApplicationSpecificInstructions which would blow up the triage guide page. 198 <Muelli> don't you think so jjardon? 199 <jjardon> Muelli, but getting traces is not a job of bugsquad team? ;) 200 <jjardon> Maybe move the pages to Bugsquad/? 201 <Muelli> actually, it's more for the bug reporter than for the bugsquad. Except a triager can reproduce the bug.. ;-) 202 <jjardon> you have to move all the subpages manually ? 203 <Muelli> *shrug* dunno. 204 <Muelli> But yeah, the GettingTraces could be moved to bugsquad namespace. But there's no real need for it too. 205 <jjardon> If yes, I think is a lot of work 206 <jjardon> maybe for the next meeting ? 207 <Muelli> Maybe. We can at least discuss if it's necessary to move or not :) 208 <Muelli> But still, was the proposal to move GettingTraces/ApplicationSpecificInstructions into TriageGuide? 209 <Muelli> And were you in favor of that jjardon? ;-) 210 <jjardon> I thik that It's necessary, but It's a lot of work if you have to move al the subpages manually ;) 211 <Muelli> but then I didn't get it. 212 <Muelli> jjardon: can you rephrase the proposal? 213 <jjardon> I'm in favor to move all GettingTraces/ApplicationSpecificInstructions pages to TriageGuide 214 <Muelli> Like copying the contents into the TriageGuide page so that it gets really huge? 215 <Muelli> 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. 216 <jjardon> no, I meant move the pages to Bugsquad/TriageGuide namespace, so you will have Bugsquad/TriageGuide/GettingTraces/ApplicationSpecificInstructions 217 <Muelli> ah. okay. Do you think that was the intention of the point on the agenda? "Add ApplicationSpecificInstructions to the TriageGuide"? 218 <jjardon> Muelli, yes, I think 219 <jjardon> but maybe would be better ask Rosana ;) 220 <Muelli> 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 ;-) 221 <Muelli> Plus, we have to update the backreferences like the stockanswers and everything 222 <Muelli> So, it's a -1 from me 223 <jjardon> Muelli, ok, you convinced me ;) 224 <Muelli> okay, next point then? andre, chromy, fabio, jjardon? 225 <fabio> :-) 226 <Muelli> "6. Refactor ProductSpecificGuidelines" - There are acutally many rules to obey. kind of a hassle. 227 <jjardon> Muelli, I vote to remove that page :) 228 <Muelli> hm jjardon. And then simply delete the information in that page? 229 <jjardon> Muelli, yes, or mark it as deprecated and start a new page 230 <Muelli> 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.. 231 <Muelli> So I'm definitely not in favor of simply deleting this information 232 <Muelli> 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. 233 <Muelli> 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... 234 <jjardon> 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 235 <jjardon> 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 ? 236 <Muelli> 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. 237 <Muelli> jjardon: what would you do different then? 238 <jjardon> Muelli, I think is more easy start a new page than cleaning the actual page 239 <jjardon> (we can send a mail to add specific rules in the new page if they want) 240 <jjardon> mail to mainteiners 241 <Muelli> 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.. 242 <jjardon> mmm, I get you 243 <Muelli> So I actually don't think that we can really improve the number of rules. But we can probably display them better. 244 <Muelli> Maybe automatically display a link to the rules in the bugzilla. 245 <jjardon> I think that we should encourage devels to follow the general rules, and in very specific cases make a specific rule 246 <Muelli> yeah sure. Is there any rule on http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines that you think is wrong or too general? 247 <jjardon> Control center: Any problems related to versions before 2.4.x can be closed as WONTFIX 248 <Muelli> 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). " 249 <jjardon> for example 250 <Muelli> yeah, it'd probably be OBSOLETE anyway. 251 <jjardon> ekiga: It is important to find out how the user installed it, whether from a distribution or from source code. 252 <jjardon> and a lot more 253 <Muelli> hm. 254 <Muelli> So we shuold probably clean them up... 255 <jjardon> or start a new page and send a mail to modules maintainers to add your own (very specific) rules 256 <Muelli> hm. 257 <jjardon> (or send a mail to gnome-desktop-devel) 258 <Muelli> 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? 259 <jjardon> maybe, but, how Can we know that they are still valid (some rules are pretty old)? 260 <Muelli> hm. which one? 261 <Muelli> I mean, in general you have to assume that the rules are valid and that maintainers come around and clean old and unneeded rules. 262 <Muelli> We could probably ask the maintainers to clean up their rules in http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines. 263 <jjardon> Muelli, +1 264 <jjardon> and if not response, remove the specific rules 265 <jjardon> what do you think? 266 <Muelli> So we need a text for a mail to be send to all maintainers or maybe d-d-l. 267 <Muelli> 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. 268 <jjardon> or we can file bugs for that, so we now if It's already fixed or not 269 <Muelli> jjardon: you mean file a bug for each rule we think is unneccesary? 270 <jjardon> file a bug for each module that It is in http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines 271 <jjardon> To say the mainteiner to update the info 272 <Muelli> And what would be the bug about? Like "Please review your rules"? 273 <jjardon> yes 274 <Muelli> 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 ;) 275 <jjardon> we can have a tracker bug to all of these bugs to track the progress 276 <jjardon> Muelli, ;) 277 <Muelli> I think writing a mail is fair enough. But yeah, if you want to file bugs, do that. 278 <jjardon> ok, Someone to write the generic and polite bug/email message ? ;) 279 <Muelli> yes ^^ 280 <Muelli> I probably can do that... 281 <Muelli> ACTION: Muelli to write a mail to be send to maintainers or d-d-l to ask for reviewing their rules. 282 <jjardon> Muelli, great 283 <Muelli> Can we actually file bugs against ourselves? That would help to keep track of the assigned tasks 284 <jjardon> Muelli, good idea 285 <Muelli> 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 286 <Muelli> yep, I'm using general... 287 <jjardon> maybe we can ask for a bugsquad module ? 288 <Muelli> yep, I mean asking is the least thing we can do :) 289 <Muelli> might be a good idea... *thinking* 290 <Muelli> maybe andre knows why we don't have such a thing already..? 291 <Muelli> hm. dunno.. do you think it'd be a good think jjardon? 292 <jjardon> I think that would be a good think, yes. So we can see open issues about meeting/actions much faster 293 <jjardon> and a mail notify us when a actions is done, we can do some actions depends on others ... 294 <Muelli> hm. 295 <jjardon> indeed, we can have a new category in the bugzilla: teams 296 <jjardon> and encourage other teams to use the bugzilla too 297 <Muelli> 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. 298 <jjardon> I think the same 299 <jjardon> where is the request tracker? 300 <Muelli> www.gnome.org/rt3 I guess. 301 <Muelli> https://www.gnome.org/rt3/ 302 <Muelli> So are you wililng to come up with a text for bugmaster, asking for a module? Or maybe directly send that CCing bugsquad... 303 <jjardon> ok 304 <Muelli> ACTION: jjardon to ask bugmaster/sysadmin to create a new "bugsquad" module in bugzilla. 305 <jjardon> what is the mail of the bugmaster/sysadmin ? 306 <Muelli> firstname.lastname@example.org I guess 307 <jjardon> ok 308 <Muelli> wondering who that acutally is.. 309 <Muelli> yep email@example.com 310 <andre> Please file a ticket in bugzilla.gnome.org against bugzilla.gnome.org if you want a new module 311 <andre> please avoid sending emails. 312 <Muelli> alright. I'm filing later on... If jjardon is not faster :-) 313 <jjardon> Muelli, send you the mail, your english is probably better ;) 314 <Muelli> k 315 <jjardon> Muelli, from http://live.gnome.org/RoadMap : "Switch from RT3 to Bugzilla" 316 <jjardon> :) 317 <jjardon> http://live.gnome.org/RoadMap#head-d1542b70c92facdb35b11856245efc7bb42a2e8d-2 318 <Muelli> 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. 319 <jjardon> Muelli, oh, ok, I dont know rt3 tool 320 <Muelli> anyway, I'm running out of power. We either have a break, or defer the last 6 (sic!) points to the next meeting. 321 <Muelli> Or you guys keep rocking while I'm having a coffeebreak... 322 <jjardon> I think is enough ;) 323 <Muelli> heh 324 <jjardon> but BugsquadGoals is a good point to discuss later ;) 325 <Muelli> yeah, well. Thank you guys for being productive again :-) I'm closing this meeting then :) 326 <Muelli> I think I'm going to wrap everything up, write a log and send that to bugsquad-l then. 327 <jjardon> great, thank you very much for your work Muelli ;) 328 <Muelli> I think the gobby was good. Though one could probably make more use of it 329 <Muelli> I for one have started to take my nodes and prepare my statements there. Others could see them and actually prepare themselves as well :-)
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.