Attachment 'bugsquad-meeting-log-2009-09-05.txt'

Download

   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 (~chromy@chello089173070061.chello.sk) ha abandonado #bugs-meet
   5 * chromy (~chromy@chello089173070061.chello.sk) 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 (~cosimoc@jalfrezi.collabora.co.uk) 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 (~fabio@200-50-107-130.static.tie.cl) 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 (~andre@g1.blanicka25.net) 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@117.192.0.244) 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> bugmaster@gnome.org I guess
 307 <jjardon> ok
 308 <Muelli> wondering who that acutally is..
 309 <Muelli> yep bugmaster@gnome.org
 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 Files

To 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.
  • [get | view] (2009-08-04 09:49:22, 56.6 KB) [[attachment:bugsquad-meeting-log-2009-08-03.txt]]
  • [get | view] (2009-09-05 18:20:58, 24.5 KB) [[attachment:bugsquad-meeting-log-2009-09-05.txt]]
  • [get | view] (2009-10-10 13:02:17, 47.8 KB) [[attachment:bugsquad-meeting-log-2009-10-09.txt]]

You are not allowed to attach a file to this page.