Aug 03 20:00:21 Hello all, seems that It's the time for the meeting, Are we all? Aug 03 20:01:04 we'll never know... ;-) Aug 03 20:01:10 :) Aug 03 20:01:20 hey torkiano Aug 03 20:01:29 hi Aug 03 20:03:39 Hello all, I'm Javier Jardón and seems that http://www.doodle.com doesn't work, murphy law :) Aug 03 20:05:45 hi torkiano Aug 03 20:07:45 Have you read the (trial) points of the day? http://live.gnome.org/JavierJardon/Bugsquad Aug 03 20:08:09 yes Aug 03 20:09:21 yep Aug 03 20:10:38 great, I hope we can reach a consensus today on most of the points :) Aug 03 20:11:57 * mkanat is here too if you have any questions about Bugzilla in general or how the upgraded Bugzilla will be. Aug 03 20:12:12 (I'm always here, it just happens to work out.) Aug 03 20:14:30 torkiano: may be we can follow your link and can discuss point by point so that we don't miss any point Aug 03 20:15:56 lakhil, yes, you are rigth. I'd like to wait for the rest of the people, but What is the average waiting time? (Sorry, It's my first bugsquad meeting) Aug 03 20:17:22 I am also attending bug squad meeting first time, in other irc meetings , we don't wait more than 10 minutes Aug 03 20:17:54 ok, let's start then Aug 03 20:17:58 So, first point: Old untouched bugs Aug 03 20:18:08 there are a lot of old bug in gnome bugzilla Aug 03 20:18:26 How we can clean the bugzilla database? Aug 03 20:18:57 as you can see in http://live.gnome.org/JavierJardon/Bugsquad, I think that we should define what is a old untouched bug Aug 03 20:19:03 first Aug 03 20:20:01 * Susana (~Susana@bl6-1-124.dsl.telepac.pt) has joined #bugs Aug 03 20:20:16 I've suggested 6 months, 1 year and 2 year, what do you think? Aug 03 20:20:32 * perror has left (Bye all !) Aug 03 20:20:35 How many bugs would each of those include? Aug 03 20:20:35 * lakhil would vote - bugs which are untouched with more than a year Aug 03 20:20:43 * mkanat could tell you that really quick. Aug 03 20:20:51 * mkanat has direct database access, will check. Aug 03 20:20:57 mkanat, great Aug 03 20:21:07 that will be great Aug 03 20:22:20 you can start thinking in what can will do with that bugs (second point) Aug 03 20:22:39 I imagine you only want open bugs. :-) Aug 03 20:22:47 oops, sorry, i'm late Aug 03 20:22:51 * andre back Aug 03 20:22:59 one vote i'd prefer Aug 03 20:23:03 ear one year Aug 03 20:23:06 ahoj andre Aug 03 20:23:09 hello andre Aug 03 20:23:18 6 months: 35384 bugs Aug 03 20:23:28 Oh wait. Aug 03 20:23:30 No, I'm doing this wrong. Aug 03 20:23:54 * lajjr (~lajjr@pool-71-181-245-145.sctnpa.east.verizon.net) has joined #bugs Aug 03 20:24:13 6 months: 14,088 bugs Aug 03 20:24:18 1 year: 23115 bugs Aug 03 20:24:22 2 years: 33227 bugs Aug 03 20:24:31 Wait no, that's not right either. Aug 03 20:24:33 * mkanat is really tired. :-) Aug 03 20:24:46 Wait no, that is right. Aug 03 20:26:11 heh Aug 03 20:26:36 well, let's look at it from another angle: after one year, the bug is already two Gnome releases back-leveled Aug 03 20:27:15 Although if it's an enhancement filed by a developer, it's probably still valid. Aug 03 20:27:22 We can't close all those bugs indiscriminately, as there are plenty of feature requests which haven't been touched for years, but are still perfectly valid Aug 03 20:27:22 I'd vote for closing all the crasher bugs (perhaps all those marked as "critical") which haven't been touched for x year(s), but nothing more invasive than that Aug 03 20:27:58 i agree with DrBob. enhancement requests are different here from "real" bug reports Aug 03 20:28:05 hi gang Aug 03 20:28:11 heja Susana Aug 03 20:28:11 +1 to DrBob Aug 03 20:28:13 yeah, I think enhacement bugs are out of this discussion Aug 03 20:28:45 And thus closing old bugs automatically is also out of the discussion (if it was ever in; I don't know) Aug 03 20:28:59 yes. i'm against automatical. Aug 03 20:29:00 That still leaves you with a lot of open old bugs: 1 year has 16045, 2 years has 22014. Aug 03 20:29:42 another issue with "one year": Aug 03 20:29:46 note that one year should be okay for modules that are part of gnome Aug 03 20:30:05 but some modules in gnome bugzilla have very long release cycles Aug 03 20:30:38 andre: How long is "very"? Aug 03 20:30:47 As long as a piece of string? :) Aug 03 20:30:57 Oh wait, no, I think I did do those numbers wrongly. Aug 03 20:31:25 Yeah, I did. Aug 03 20:31:40 no matter what, I think there is consensus in that closing old bugs will be a manual process Aug 03 20:31:50 it can be helpful to look at the FTP server for the release date when cleaning up a specific module that is NOT official part of GNOME. Aug 03 20:32:06 i must admit that i cleaned up gnome-commander a few days back Aug 03 20:32:06 Not necesarily: I think we could get away with automatically closing critical bugs which haven't been touched in x year(s) Aug 03 20:32:07 Here's a breakdown of bugs that haven't been touched in one year, by severity: http://pastebin.mozilla.org/665509 Aug 03 20:32:29 i used the following comment for that: http://bugzilla.gnome.org/show_bug.cgi?id=477506#c1 Aug 03 20:32:30 Bug 477506: critical, High, 1.2.5, epiotr@use.pl, RESOLVED OBSOLETE, crash in GNOME Commander: Aug 03 20:32:31 DrBob, +1 Aug 03 20:32:45 * lajjr_ (~lajjr@pool-71-181-245-145.sctnpa.east.verizon.net) has joined #bugs Aug 03 20:32:46 though i nowadays vote for setting them to NEEDINFO first and not directly closing :) Aug 03 20:32:47 * lajjr has left (Read error: 104 (Connection reset by peer)) Aug 03 20:32:48 We shouldn't close blockers, but perhaps bump them (automatically or manually would work) Aug 03 20:33:05 * lajjr_ is now known as lajjr Aug 03 20:33:19 Why on earth we have blockers which haven't been touched for a year is confusing Aug 03 20:33:39 DrBob: I'll get you the bug numbers. Aug 03 20:34:57 Or I'll just generate a search. Heck. Aug 03 20:35:00 DrBob, e.g. because sometimes users file them as blockers ("doesn't work for me so it must have highest importance) and some developers don't care about correcting this field Aug 03 20:35:11 andre: Yeah, that seems to be the case with most of these. Aug 03 20:35:23 Silly developers Aug 03 20:35:28 that's not too generalize of course. i know developers that are very picky about the sev/pri fields in b.g.o Aug 03 20:37:31 * alexg has left (Abandonando) Aug 03 20:37:41 so i think we agree on one year for crasher/blocker reports and manual checking? Aug 03 20:37:48 what about untouched non-crasher non-enhancement bugs? Aug 03 20:38:04 DrBob: they're eavesdropping... Aug 03 20:38:28 andre: I am not sure closing them blindly will be fair Aug 03 20:38:37 andre, I vote for close them too (or set needinfo) Aug 03 20:38:57 +1 for needinfo Aug 03 20:39:11 * lakhil prefers to move them to needinfo, wait for reporter’s reply within given time period and then close the bug Aug 03 20:39:18 lot of people forgot the bug report, and they can reopen the bug if they want Aug 03 20:39:18 i'm also definitely against blindly. Aug 03 20:39:22 +1 for lakhil :) Aug 03 20:40:05 +1 for lakhil Aug 03 20:40:42 so bugs (not enhacement) > 1 year -> Let reporter to try a new version and set NEEDINFO ? Aug 03 20:41:04 *not enhancement and not critical/blocker Aug 03 20:41:21 yes. THEN what? close in? Aug 03 20:41:29 critical are often the automatic crash reports, though Aug 03 20:41:34 those should go, too Aug 03 20:41:50 one day/week/month/quarter/semester/year? Aug 03 20:42:12 not to forget to mention in which stable version user should try and report back Aug 03 20:42:49 set needinfo and close after 3 months as OBSOLETE in this case sounds save to me. maybe one month is fine too, but i feel better with 3 months Aug 03 20:43:07 yes, we need a *good* stock answer for this Aug 03 20:43:56 +1 for 3 months. Aug 03 20:44:04 andre, I like your answer in bug http://bugzilla.gnome.org/show_bug.cgi?id=477506#c1 Aug 03 20:44:05 Bug 477506: critical, High, 1.2.5, epiotr@use.pl, RESOLVED OBSOLETE, crash in GNOME Commander: Aug 03 20:44:09 yes, basically i prefer to have the last sentence to be sth like "Thank you for reporting this bug and we are sorry it could not be fixed for your version." because Aug 03 20:44:19 somebody took his/her volunteer time to report an issue Aug 03 20:44:29 and "we" (gnome) didn't really care Aug 03 20:44:34 that happens and is reality. Aug 03 20:44:53 but can be disappointing to a reporter not used to open source :) Aug 03 20:47:20 I think the time should be the same for all NEEDINFO bugs (next point) Aug 03 20:47:41 +1 for torkiano Aug 03 20:48:03 Ubuntu, for exmaple, waits 6 weeks Aug 03 20:48:13 hmm. i agree Aug 03 20:48:37 +1 for 6weeks. Aug 03 20:48:48 * muelli (~muelli@78-59-18-15.static.zebra.lt) has joined #bugs Aug 03 20:49:02 ahoi Aug 03 20:49:04 4 to 6 weeks is good enough time period to wait for reporter’s response Aug 03 20:49:22 Agreed Aug 03 20:49:43 sorry for being late. /me is still in holidays... :) Aug 03 20:49:58 muelli: ahoj :) Aug 03 20:50:01 OK. can someone please summarise that? Aug 03 20:50:35 so bugs (not enhacement and not critical) > 1 year -> Let reporter to try a new version and set NEEDINFO -> 6 weeks -> close as INCOMPLETE? Aug 03 20:50:57 I think criticals should be in there, too Aug 03 20:51:03 Yes, plus automatically close criticals Aug 03 20:51:04 yeah, what's with blockers? Aug 03 20:51:12 errrrr crashers Aug 03 20:51:27 DrBob, +1 Aug 03 20:52:16 i'd include crashers here. Aug 03 20:52:31 yes Aug 03 20:52:51 crashers == criticals , isn't it? Aug 03 20:53:02 For all intents and purposes, yes Aug 03 20:53:02 most of the time Aug 03 20:53:03 in 90% of the cases, yes Aug 03 20:53:19 so we use "INCOMPLETE" here after NEEDINFO (sounds good) and we leave the "OBSOLETE" resolution for bugs *newly filed* against *ancient* versions? great :) Aug 03 20:53:28 Yup Aug 03 20:53:37 andre, yes Aug 03 20:54:45 so will we close critical bugs automatically after 1 year? Are we agree? Aug 03 20:55:33 (untouched critical bugs, I mean) Aug 03 20:55:53 +1 from me Aug 03 20:56:17 shouldn't they also be set to NEEDINFO first? Aug 03 20:56:51 after all, if people can still reproduce the crash it's still valid Aug 03 20:56:54 * muelli nods Aug 03 20:56:56 fizz: +1, after following NEEDINFO -> 6 weeks process Aug 03 20:57:14 yes. all the same. +1 Aug 03 20:57:29 sounds good Aug 03 20:57:31 * rego (~rego@104.Red-83-37-184.dynamicIP.rima-tde.net) has joined #bugs Aug 03 20:57:41 * fer (~fer@73.Red-81-32-106.dynamicIP.rima-tde.net) has joined #bugs Aug 03 20:57:43 fizz, +1, I think the more generic are the rules, the better Aug 03 20:57:50 cool. complete agreement. :) Aug 03 20:59:16 also keep in mind that not all enhancements are correctly flagged as such... Aug 03 20:59:16 Sorry for asking, but do we have an agenda we're working on? Aug 03 20:59:38 muelli, http://live.gnome.org/JavierJardon/Bugsquad ? Aug 03 20:59:56 I frequently see them come in as minor, for example Aug 03 21:00:43 we need a stock response for old untouched bugs, or maybe we can use this: http://live.gnome.org/Bugsquad/TriageGuide/StockResponses#head-365a0993c0ba2386a8f779d05389bd1de3fefd0c Aug 03 21:00:45 yes, reporters often think that their issue is a bug. but the line is never clear Aug 03 21:01:10 torkiano, that one is only for *newly* reported bugs about old versions Aug 03 21:01:43 mmm, I meant, we can adapt that stock response Aug 03 21:03:49 right, let me come up with something... Aug 03 21:04:27 great, Can we go to the next point : use of NEW status? Aug 03 21:05:10 "This bug was reported against a GNOME version that is now not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Aug 03 21:05:10 Please check if the problem you reported here still occurs with a recent version of GNOME by reporting back which exact version you tested against" Aug 03 21:05:16 ^^ maybe? Aug 03 21:05:46 andre, I like it Aug 03 21:05:55 ah wait Aug 03 21:05:57 "Thank you for reporting this bug and we are sorry it could not be fixed for your version." Aug 03 21:06:01 plus that one at the end. Aug 03 21:06:05 yes Aug 03 21:06:07 ...other comments? Aug 03 21:06:08 I guess you should also mention that it will be closed after 6 weeks if there's no response Aug 03 21:06:19 fizz, +1 Aug 03 21:06:24 fizz, +1 Aug 03 21:06:29 (that's what fedora also does) Aug 03 21:06:33 yes +1 very good. Aug 03 21:06:58 (and that's what we should do on Ubuntu...) Aug 03 21:07:20 "Without feedback by the reporter this report will be closed as INCOMPLETE in 6 weeks." ? Aug 03 21:07:32 +1 hggdh . Aug 03 21:07:40 not necessarily by the reporter, I'd say Aug 03 21:07:57 right Aug 03 21:08:01 6 weeks seems like a good deadline. Aug 03 21:08:04 "Without feedback this report will be closed as INCOMPLETE in 6 weeks." ? Aug 03 21:08:27 ack Aug 03 21:08:33 andre, +1 (and you beat me to the retype ;-) Aug 03 21:08:43 andre, +1 Aug 03 21:08:45 +! Aug 03 21:08:47 +1 Aug 03 21:08:53 +1 :) Aug 03 21:08:55 by doing just that in 6 week the bugs will be cut in half. Aug 03 21:08:57 +1 Aug 03 21:09:22 lajjr, yes, but frankly, after one year, it is time Aug 03 21:09:47 yes Aug 03 21:10:05 and when we close bugs as INCOMPLETE, we tall reporter that he can reopen the bug if he want Aug 03 21:10:40 http://live.gnome.org/Bugsquad/TriageGuide/StockResponses#head-dbbf91a496f5f6460a459159b976fa72a454a7a0 Aug 03 21:11:15 Yes reopen if he has info to add or a way to reproduce it. Aug 03 21:12:23 on a newer version... Aug 03 21:14:12 ok, Can we go to the next point : use of NEW status ? Aug 03 21:14:51 What's the point with it, torkiano? Aug 03 21:15:17 * Susana_ (~Susana@bl6-17-76.dsl.telepac.pt) has joined #bugs Aug 03 21:16:23 muelli, well if we really use that status, what it mean? CONFIRMED or TRIAGED ? Aug 03 21:16:48 what is the difference between those both? Aug 03 21:17:04 I consider it something the developers should set, to signal that they've noted a bug and agree that it *is* a bug Aug 03 21:17:06 CONFIRMED, of course :) there's this page I can't find anymore. "What do all these fields mean anyway?" and it writes, basically, that NEW is a confirmed bug. Aug 03 21:17:29 http://bugzilla.gnome.org/page.cgi?id=bug-status.html#status ? Aug 03 21:17:42 muelli, we can change that ;) Aug 03 21:17:42 well andre. The difference is, that you, as a triager, don't want to see triaged bugs in your search list. Aug 03 21:18:03 sure torkiano. But I don't know why we should do that :) Do you see any problem? Aug 03 21:18:09 yep andre. thanks. Aug 03 21:18:27 TRIAGED means that is a bug with all the info needed for a developer can fix it Aug 03 21:18:30 Yep. A bug is NEW if it can be picked up by a bored developer of volunteer. Aug 03 21:19:41 * Drom (~Dromatko@213.191.119.2) has joined #bugs Aug 03 21:19:46 torkiano, there is no official distinction between confirmed and triaged on b.g.o. Aug 03 21:19:47 I wouldn't necessarily say so, torkiano. If everything is "ready to fix", it should be new. Basically, a bug should not be in UNCONFIRMED anyway. Aug 03 21:20:22 But that's in utopia because we were too lazy in the past... ;-) Aug 03 21:20:31 not sure if confirmed or new resolution makes any difference in attracting a developer Aug 03 21:20:54 if confirmed it is reproducible. Triaged is when someone picks it up to work on it. Is a good way to look at it. Aug 03 21:21:08 if a developer changes the state , it makes more sense Aug 03 21:21:09 I would say current usage here is that NEW is prime territory for fixers Aug 03 21:21:27 I mean, the only problem I see with not having a TRIAGED state is, that you might get triaged bugs in your result list if you're looking for something to do. But I don't see it as a big enough problem to take care of that. Does anybody disagree? Are there other problems I don't see atm? Aug 03 21:21:36 hggdh, muelli we can make that distinction, so developers know that these bug has more info and has been reviewed for the bugsquad team Aug 03 21:22:00 (a bug with the NEW status, I mean) Aug 03 21:22:28 muelli: the problem of people comming to irc asking for someone to change their bugs from unconfirmed Aug 03 21:22:56 yeah sure torkiano. As I'm saying, a bug should be NEW if it's ready to fix. but there might be cases where UNCONFIRMED is still a valid state. i.e. when the developers should discuss a bug on a mailinglist. NEW or NEEDINFO would be a wrong state. Aug 03 21:23:23 * Susana has left (Read error: 145 (Connection timed out)) Aug 03 21:23:28 they think that unconfirmed is neglicting Aug 03 21:23:29 well Susana. I have never experienced that, but there should be a reason why a bug is not NEW. If there is none, it should be NEW... :) Aug 03 21:24:29 muelli: some developers don't like it when other people set their bugs to new Aug 03 21:24:56 I'd say the only one able to really decide whether it's more than unconfirmed is a dev Aug 03 21:24:58 because to them new is "I have seen it and i'm thinking about implementing ths soon" Aug 03 21:25:04 Susana_, true Aug 03 21:25:08 or put differently Aug 03 21:25:18 * mbarnes is now known as mbarnes|afk Aug 03 21:25:30 muelli, so you said that NEW=TRIAGED (ready to work on it (it has all the info a devel would need)) ? Aug 03 21:25:31 are you really sure the problem is in the module the bug has been filed against? Aug 03 21:25:37 Do you have an example Susana_? Because I can't really imagine how anybody can be against setting a bug to NEW if it really is ready to fix. Aug 03 21:25:46 just as an example Aug 03 21:26:12 * Drom has left (Leaving.) Aug 03 21:26:33 gimp developers can be really... different when triaging their bugs for example. Aug 03 21:26:51 "don't confirm enhancement requests, they have to be discussed on the mailing list first!" Aug 03 21:27:13 muelli: that's one. I dislike people setting my bugs to NEW when the bug isn't actually in my module (or GNOME, or maybe there really isn't any bug at all) Aug 03 21:27:26 especially for enhancements, yes Aug 03 21:27:28 well. I see. whlie I fully understand that different developers have their own habits, I believe we should encourage other people to contribute to the project as well. And I believe, that a bug, which is ready to fix, should be set to NEW whatsoever because a volunteer might cross the bugzilla and pick a ready-to-fix task. Aug 03 21:27:55 muelli: define "ready to fix" Aug 03 21:28:27 fizz: good stacktrace, prolly some duplicates, so that you know that a special function crashes. Aug 03 21:29:13 that might work for crashers, although the owning module could still change Aug 03 21:29:14 I wouldn't set enhancements to NEW though,if I'm not reading the developer mailinglist and know that this particular issue is on the roadmap. Aug 03 21:29:16 +1 for fizz Aug 03 21:29:21 yep, I see that. Aug 03 21:29:26 I think NEW should only be set by developers Aug 03 21:29:39 muelli, so TRIAGED, not only CONFIRMED ;) Aug 03 21:30:24 but still, the problem we're discussion about, are reporter who feel that nobody takes care of their issue, right? (Because the status is still UNCONFIRMED). And if the reporter filed an enhancement and the maintainer haven't decided to implement that, it's simply not confirmed and thus not NEW :) Aug 03 21:30:31 torkiano: not yet ;-) Aug 03 21:31:26 there is a possible change in behaviour: I think it should be NEW if (a) confirmed; (b) enough data for a developer to lokk at Aug 03 21:31:38 argh. look Aug 03 21:31:59 :) Aug 03 21:32:04 * hggdh has to remember not to talk/code much after a sleepness night Aug 03 21:32:11 or type Aug 03 21:32:16 * muelli gets himself a beer. Aug 03 21:32:36 * Drom (~Dromatko@213.191.119.2) has joined #bugs Aug 03 21:32:40 darn! All I have if coffee! And American, at that :-( Aug 03 21:33:17 so, have you finished your point hggdh? Or are you still thinking and writing? ;-) Aug 03 21:33:26 * lakhil (~Administr@117.192.29.234) hat #bugs verlassen Aug 03 21:33:32 heh. yes, I made my point. I think. Aug 03 21:33:48 today NEW = CONFIRMED and is not very used. I think that if we change to NEW=CONFIRMED, the NEW status will have more value Aug 03 21:34:51 well, really, it is just a name. It is the *usage* that is important. A NEW bug is, by definition, what other BTSs would call confirmed (like launchpad, for example) Aug 03 21:35:29 true Aug 03 21:35:44 ideally, we'd simply have a Triaged checkbox or something Aug 03 21:35:57 if we change to NEW=TRIAGED, I mean Aug 03 21:36:55 or just add a TRIAGED state though I suppose an additional state has other costs Aug 03 21:37:11 I think it would be better to have it this way: since there is no triaged status, a bug will go from unconfirmed to new to . Adding a new status will be a major operation Aug 03 21:37:37 I still don't see the problem we're trying to solve :( I don't see people joining #bugs and complaining about their bug not being cared of as a real problem, because their bug might simply not be confirmed Aug 03 21:38:31 as long as it's not a problem for bugsquadders I agree with muelli: not an issue Aug 03 21:38:41 +1 Aug 03 21:38:44 whiteboard and keywords generate bug mail right? maybe we could use some field that doesn't generate spam to flag triaged bugs only internaly.. Aug 03 21:39:04 muelli, It'll be confirmed (NEW) when the bug has the enougth information Aug 03 21:39:24 i also don't think it's important to change current behaviour Aug 03 21:39:27 there is also that. We might be able to "test" the concept by abusing some non-spammable field, yes. Good idea. Aug 03 21:39:51 torkiano: sure :) I mean, there is (of course) no definition for "enough information". So in question, either ask here, on bugsquad-list or risk getting a flame ;-) Aug 03 21:40:28 andre, I agree: I think it is important to minimise behaviour changes Aug 03 21:41:07 So torkiano. Do you think the issue with the NEW./.TRIAGED state has suffincently be discussed? Anybody else? Aug 03 21:41:40 muelli, gnome version, distribution used, version of the program ... easy info that lots of time is missed Aug 03 21:41:45 muelli, of course ;) Aug 03 21:41:54 * Drom has left (Leaving.) Aug 03 21:42:44 it would be good if downstream bugs always included the downstream bug link Aug 03 21:42:44 Susana_, andre, DrBob, fizz, ... Anything to add to the NEW vs. TRIAGED point? Did I get it right, that we'll do nothing in this regard? Aug 03 21:42:54 i wouldn't change it currently Aug 03 21:42:58 fine with me Aug 03 21:43:13 hggdh: +1 Aug 03 21:44:01 sounds good to me. So let's close that TRIAGED point. Next is the downstream problem..? Aug 03 21:44:01 we try to do that with Ubuntu bugs, everywhere we open an upstream bug. Although not all devs will go there, it is a refback Aug 03 21:44:31 it's a nuisance when *only* the link is posted, though Aug 03 21:44:32 hggdh, we can do that with bugzilla 3.4, I think Aug 03 21:44:59 well. I agree that it'd be nice to have the backreference. It'd be good if the BTSs could speak to each other :-\ I actually don't want to check manually :( Aug 03 21:45:04 fizz, indeed. The refer-back link is *additional* data Aug 03 21:45:13 torkiano, really? Aug 03 21:45:55 hggdh, http://www.bugzilla.org/releases/3.4/release-notes.html#v34_feat_see Aug 03 21:46:00 yes Aug 03 21:46:06 We could ask downstream to give their link if they file a bug upstream though. Wouldn't be bad to have contact with downstream anyway. Aug 03 21:46:36 still i want people to paste the text in b.g.o. i don't want to click a downstream link to read the report or see some screenshots Aug 03 21:46:44 time is precious. Aug 03 21:46:50 especially for developers Aug 03 21:47:06 +1. On Ubuntu we are moving (or trying to) to set official contacts to upstream Aug 03 21:47:17 andre: it'd be your job as a triager to minimize the time a developer needs to fix an issue then ;-) Aug 03 21:47:31 But again: Is this a problem? I remember Debian and Ubuntu bugs which AFAIR always have the reference. Aug 03 21:47:31 true Aug 03 21:47:41 yeah, i don't see an issue either. Aug 03 21:48:42 * lajjr_ (~lajjr@71.181.209.2) has joined #bugs Aug 03 21:48:59 But let's follow the downstream contact thing. I think it'd be nice to be a contact person for downstream. So I think I like if we introduce ourselves to, e.g. fedora bugsquadders and ask them to ask us in case of any problems with the GNOME bugzilla or any triager being rude and stuff... Aug 03 21:49:22 Just a spontanous idea though. Dunno if the work is really worth it. Aug 03 21:50:26 So do we have any volunteers introducing themselves to, say, Fedora, Debian, Gentoo, .. I think we are well equiped with Ubuntu guys :) Aug 03 21:51:19 i think in fedora forwarding is done by downstream developers, no "single point of failure" :-P Aug 03 21:53:07 hm. So let's not do anything with that regard. I'll try to come up with a more elaborate next meeting... Or does anybody want to discuss having contact to downstream now? DrBob, Susana_, fizz, hggdh, etc..? Aug 03 21:53:19 i don't really need it :) Aug 03 21:53:30 not me Aug 03 21:54:09 * andre looks at the clock ;-) Aug 03 21:54:12 torkiano, you said, that version and other easy metadata is missing often? That'd be uncool of course. So I propose that we'll fill the data once we see missing fields ;-) Aug 03 21:54:21 can we search for such bugs missing that easy metadata? Aug 03 21:55:27 i don't think it's that important. only fixing that creates lots of bugmail. but when triaging/changing a bug it's nice to set, yes Aug 03 21:55:40 +1 Aug 03 21:56:03 * lajjr has left (Ping timeout: 600 seconds) Aug 03 21:56:16 * muelli waits for other people to react ;-) Aug 03 21:56:22 +1 Aug 03 21:56:30 time out. okay. next topic. ;-) Aug 03 21:57:10 * mbarnes|afk is now known as mbarnes Aug 03 21:57:19 Should we use NOTABUG resolution? (How to deal with suggestions request) Aug 03 21:57:29 yeah, couldn't make anything out of it yet Aug 03 21:58:19 See what Ubuntu does here: https://wiki.ubuntu.com/Bugs/Responses#An idea to improve Ubuntu Aug 03 21:58:23 i leave that up to developers Aug 03 21:58:24 I mean, we have a NOTABUG resolution :) And I use it from time to time Aug 03 21:58:24 :) Aug 03 21:58:35 torkiano, please post URLs with %20 :-) Aug 03 21:58:44 it's about enhancement requests only Aug 03 21:58:52 suggestion requests are enhancements, if put them in a separate place we willhave to triage two places Aug 03 21:59:13 well andre. I mostly close NEEDINFO as NOTABUG if the discussion was about why this would be a bug, f.e. Aug 03 21:59:34 muelli, ...for enhancement requests? Aug 03 21:59:46 URL was https://wiki.ubuntu.com/Bugs/Responses#An%20idea%20to%20improve%20Ubuntu Aug 03 21:59:52 I use it for when people want to change, e.g., the default behaviour, and they're wrong Aug 03 22:00:02 torkiano, that's not what Ubuntu does. It's just a proposal to Ubuntu. Aug 03 22:00:10 yeah. i don't see any issue here/. Aug 03 22:00:13 andre: AFAIR I closed enhancements as WONTFIX if the maintainers showed that it's not an issue. Aug 03 22:00:23 muelli, yes, +1 Aug 03 22:00:50 But stuff like "video doesn't play in totem" and the reporter was asked to set from Xine to GStreamer but hasn't done it yet (or so..) then I closed as NOTABUG IIRC. Aug 03 22:01:39 muelli: That should probably be OBSOLETE instead Aug 03 22:01:42 So in short: I don't see any problem we need to discuss :) And, just if it's not clear: I don't think a brainstorm.gnome.org is a good idea for GNOME. Aug 03 22:01:54 i also don't see a problem. Aug 03 22:02:02 yeah DrBob. In that particular example you might be right. Aug 03 22:02:33 great; next point, then? Aug 03 22:02:34 so torkiano, do you want to elaborate on that? i.e. what problem you see we have or how we can improve our bugexperience? ;-) Aug 03 22:02:49 sure, If you (or anybody else) don't want to add anything :) Aug 03 22:03:42 I understand better now the NOTABUG status Aug 03 22:03:53 :) good :) Aug 03 22:04:16 So I'll just pick the next point then (sorry for speeding a little...) Aug 03 22:04:16 # Discuss the severity and priority fields (kill priority field? (a bit confusing for novices, is really useful?)) Aug 03 22:04:29 if novices don't know they shouldn't touch it. Aug 03 22:04:35 nothing to remove here, developers use it. Aug 03 22:04:41 well, I don't think we have to do anything. Novices are not actively encouraged to fiddle around with the knobs anyway. OTOH I don't know if these are actively used by the maintainers anyway. Aug 03 22:04:47 Oh, do they...? Aug 03 22:05:10 sometimes, yes :) Aug 03 22:05:27 well, I mean if we have them, they are free to use them and they don't disturb us in any way. At least I don't see why they should disturb us, because I don't think that they are a problem for noobs. Aug 03 22:05:36 that is the point, is really used? Aug 03 22:05:40 s/think/know/ Aug 03 22:05:55 ah, forget about that Aug 03 22:07:19 so, next point then :) ? Aug 03 22:07:24 well torkiano. I actually don't care if anybody uses them or not. In fact, I think they can help organize tasks but I am totally fine if anybody doesn't use them... Aug 03 22:07:36 Not using them doesn't disturb me :) Aug 03 22:08:03 they are being used Aug 03 22:08:21 ok, so that field is only used by the developers? Aug 03 22:08:32 Yeah, definitely. Aug 03 22:08:40 More maintainers probably. Aug 03 22:08:57 there more or less equivalent ;-) Aug 03 22:09:06 ok, maybe we can said it somewhere Aug 03 22:09:07 s/there/that's/ Aug 03 22:09:14 I mean if you happen to know the roadmap, you might know what priority several bugs have and thus can set this status accordingly... Aug 03 22:09:45 yeah fizz, you're right. But we have a couple of bigger projects though :) Aug 03 22:10:48 so, next? Aug 03 22:10:59 well, and severity is a bit odd. It should mean how big the impact^tm of a bug is. So that's mainly used for crashers in the GNOME bugzilla and developers are free to set that according to their flavour. Although I haven't seen anybody resetting that... Aug 03 22:11:40 * fizz has... Aug 03 22:11:53 It's set to "very high" for crashers by default. So feel free to set that to the highest severity if anybody has filed a bug himself and not, e.g. though bugbuddy Aug 03 22:12:03 yeah next then ;-) Aug 03 22:12:15 Kill VERIFIED and CLOSED status ? Aug 03 22:12:29 closed? Aug 03 22:12:38 (They are not used) Aug 03 22:12:40 same as for the former one: i don't see a big issue, but i have seen (very very few) developers using it Aug 03 22:12:57 torkiano, why are they not used? did you query in gnome bugzilla for bugs with that status? Aug 03 22:13:01 I've used VERIFIED a few times Aug 03 22:13:16 Sorry, not very used Aug 03 22:13:25 one very good use for pri is that downstream usually uses nor for crashers which distincts them from bugbuddy Aug 03 22:13:29 i also use VERIFIED now but I admit that's because of the workflows a big company pushed me into :-P Aug 03 22:13:57 good for someone who is triaging and doesn't want to see them Aug 03 22:14:17 I sometimes see reporters using VERIFIED, too, after a fix has been applied (and possibly released) Aug 03 22:14:17 i admit they are quite useless in b.g.o, but not totally useless :-) Aug 03 22:14:23 heh Susana_. Good catch. Is there anything we want to do about that? (FWIW: I don't). Aug 03 22:14:28 however i have not seen anybody being confused by it. so keep it. Aug 03 22:14:58 +1 ONE DAY THEY MAY GET TO BE USED Aug 03 22:15:06 * hggdh begs pardon Aug 03 22:15:14 muelli: I like it, i know i don't need to check for dups in those cases (seb or pedro bugs) Aug 03 22:15:30 hhe Aug 03 22:15:36 we could change stock answers to tell the reporters "once this has been released by your distro feel free to verify" Aug 03 22:15:41 good Susana_. Back to the other thing then :) Aug 03 22:15:50 heh, seb has filed his share of dupes ;-) Aug 03 22:15:55 uh, how would I set VERIFIED anyway? :D Aug 03 22:16:15 muelli: It's an option once a bug is RESOLVED Aug 03 22:16:25 "Leave as RESOLVED INCOMPLETE Aug 03 22:16:25 Reopen bug Aug 03 22:16:25 Mark bug as VERIFIED" Aug 03 22:16:53 how much email will be generated? Aug 03 22:17:30 it's a state change, so anybody subscribed to that will get mail Aug 03 22:17:41 uh, I though this VERIFIED is the same as NEW. So if a bug is CLOSED but wasn't NEW, I though you can REOPEN and set it to NEW... *shrug*. Aug 03 22:17:53 I think verified is an extra step to garanty quality after a fix has been delievered, it is important but it involves even more work Aug 03 22:18:05 {FIXED,WONTFIX,OBSOLETE,whatever} -> VERIFIED -> CLOSED Aug 03 22:18:22 +1 Aug 03 22:18:31 especially because it only makes sense to be vefied by the people who see the bug Aug 03 22:18:33 a developer closes as FIXED, a reporter then closes as VERIFIED, a product manager then closes as CLOSED Aug 03 22:18:40 yeah, doesn't apply to gnome ;-) Aug 03 22:18:56 but still is a good flow from the QA perspective Aug 03 22:19:03 uh Aug 03 22:19:07 muelli, http://en.wikipedia.org/wiki/File:Bugzilla_Lifecycle_color-aqua.svg Aug 03 22:19:10 kinda redundant Aug 03 22:19:28 not really Aug 03 22:19:32 for GNOME at least ;-) Aug 03 22:19:33 but probably highly important for tieish companies ;-) Aug 03 22:20:58 So the discussion is about what exactly? To kill VERIFIED and CLOSED? Aug 03 22:21:07 muelli, I agree that is a bit redundant (I vote for kill those status), but I think that andre idea is good: " we could change stock answers to tell the reporters "once this has been released by your distro feel free to verify"" Aug 03 22:21:28 ah, now I get it. Yeah, that sounds good to me. Aug 03 22:21:31 not a bad idea Aug 03 22:21:32 muelli: Yes it is Aug 03 22:21:56 are we agreed on it? +1 from me Aug 03 22:22:01 +1 okay. ACTION: change stock answer encouraging reporter to verify after fixed Aug 03 22:22:03 andre: Are you willing to rewrite those stock answers and present them either later here in the meeting or during the next meeting? Or maybe in the meantime on bugsquad-list..? Aug 03 22:22:15 muelli, i can do that, but not before the weekend comes Aug 03 22:22:16 +1 Aug 03 22:22:28 it's in bugzilla-newer in git for any volunteers Aug 03 22:22:44 yeah andre. sure. take your time. Bugsquad hasn't moved for a long time, don't start hurrying now ;-) Aug 03 22:23:00 andre: the stockanswers you mean? Aug 03 22:23:13 yes, stockanswers Aug 03 22:23:18 which will get displayed below the textarea in bugzilla? Aug 03 22:23:24 andre, I can help you sending the patches, If you want Aug 03 22:23:25 with that javascript magic? Aug 03 22:24:19 ok, next? Aug 03 22:24:25 * lajjr_ is now known as lajjr Aug 03 22:24:27 yeah, good. Andre and torkiano do that :) awesome Aug 03 22:24:41 * Susana_ is now known as Susana Aug 03 22:24:44 "What to do with bugs about deprecated modules?" Aug 03 22:24:44 * seb128 (~seb128@89.127.177.75) has joined #bugs Aug 03 22:24:55 * licio has left (Leaving) Aug 03 22:25:02 proposal: talk to maintainer(s) of deprecated module first Aug 03 22:25:27 e.g. i talked to hadess (nautilus-cd-burner) and he himself wanted to close the remaining open tickets. Aug 03 22:25:31 hm. good question. So the problem could be, that time will be bound by people because they see it in the buglist or get mail from (maybe) obsolete bugs. Aug 03 22:25:32 (and did a few days back) Aug 03 22:25:38 If the deprecated module was superseded by something else, see if any of the bugs are applicable to the new module. Otherwise, nuke 'em Aug 03 22:25:52 DrBob, i can't test 600 gnome-vfs bugs against gio/gvfs Aug 03 22:26:06 That is true, but it might be feasible for the smaller modules Aug 03 22:26:25 i closed some of them (the enhancement requests against gnome-vfs) a few months back and two people complained that i should have tested first Aug 03 22:26:38 told them it's ridiculous and they themselves should take care about the bugs they reported. Aug 03 22:26:46 Fair enough Aug 03 22:26:51 so, andre's proposal: talking with the maintainer first is a good idea. Aug 03 22:26:51 I actually wouldn't do much about it for, say, two years or so. f.e. Debian decided to have such long release cycles IIRC and they could use the information in the bugs for anything we probably can't imagine now. Aug 03 22:27:00 I can help if you give a task for me to do? Aug 03 22:27:10 I vote to close all the enhacementes bugs Aug 03 22:27:10 muelli, they can still use the info when the bug is closed. we don't remove info Aug 03 22:27:15 can't we tell the reporter the module is deprecated and ask them to see if it is valid for new product? Aug 03 22:27:35 not necessarily true andre: If they wanted to compile a list of known bugs, they would be lost Aug 03 22:28:01 muelli: If all the bugs are closed with a stock message and perhaps a known status keyword, they'll be easy enough to find Aug 03 22:28:14 And these bugs of obsolete modules don't disturb us, do they? Aug 03 22:28:17 proposal: 1) talk to maintainer first and get agreement (only one triager please, CC bugsquad list?), 2) add a warning comment that module is now deprecated and to please check against potential new module (like Susana wrote), 3) otherwise close 6 weeks later if untouched Aug 03 22:28:24 without closing, just to try to get a reaction Aug 03 22:28:40 i want a clean bugzilla. so they do disturb me, yes. Aug 03 22:28:44 sure DrBob. I'm not saying to not close them at all. But to close them not that early. Aug 03 22:29:08 muelli: And I'm saying we can close them that early Aug 03 22:29:15 people only care when put under pressure. Hence when I close gnome-vfs tickets people finally retested against gvfs/gio and reassigned Aug 03 22:29:31 muelli, i still don't see a reason why not to close. Aug 03 22:29:36 they can query for closed bugs always. Aug 03 22:29:55 andre, I vote for 2->3 Aug 03 22:30:08 torkiano, i don't understand Aug 03 22:30:10 * fer has left (Read error: 104 (Connection reset by peer)) Aug 03 22:30:39 warning comment + summarilly closed after 6 weeks on default Aug 03 22:30:49 hggdh, thank you ;) Aug 03 22:30:52 sure andre. But it's a lot more complicated to search for closed bugs which were obsolete by the time the module was obsoleted than just getting the list of new bugs. Aug 03 22:30:54 i want to talk to maintainer first. always. Aug 03 22:31:11 people get pissed quite easily i can tell you. it's still cat herding ;-) Aug 03 22:31:23 hence i proposed 1->2->3 :-P Aug 03 22:31:42 I agree. If we know the maintainer (and we should ;-), 1; 2; 3 bang! done Aug 03 22:32:17 And it just disturbs your esthetical taste, not our work in general, so I don't see an immediate need to close them in, say, the next 6 weeks. Aug 03 22:32:33 muelli, it slows down queries for open bugs. Aug 03 22:32:38 it's not aesthetical Aug 03 22:33:24 but since I'm not from a distro that makes use of deprecated modules (in fact, I'm not from a distro at all) closing them doesn't really disturb me... But I feel it'd be nice to write to, say, Debian in case they want to mirror the current information. Aug 03 22:33:51 How long should we wait for a response from the maintainers? Aug 03 22:33:57 andre: I don't think that. Aug 03 22:34:20 torkiano, normally they are responsive. as I propose to CC bugsquad mailing list, we could still discuss on the ML if there is no answer Aug 03 22:34:24 no need for a rule i'd say Aug 03 22:34:43 andre, +1 Aug 03 22:35:41 [2] and set the bug as NEEDINFO, rigth? Aug 03 22:36:23 hggdh: do you know debian bugsquadders that might be interested in bugs for currently OBSOLETE modules? Aug 03 22:36:46 torkiano, [2]: oh, right :) Aug 03 22:38:01 * fizz has left (Read error: 104 (Connection reset by peer)) Aug 03 22:38:33 * fizz (~fizz@ip-81-210-151-47.unitymediagroup.de) has joined #bugs Aug 03 22:38:56 hm. Aug 03 22:39:37 muelli: maybe when we contact the developer and cc bugsquad we could also CC gnome-debian or debian-gnome (don't remember if it is one or the other) Aug 03 22:40:27 but i know the is a gnome list for debian maintainers Aug 03 22:40:32 *there Aug 03 22:40:57 Susana: we probably need to do that one time. Like "dear downstream, we're about to close all bugs from obsolete modules which are: foo, bar, baz. Please copy the information you need now, or find the informatino later by querying for "closed and keyword obsolete-module" or so. Aug 03 22:42:09 muelli, we can do that when we receive the response from the maintainer Aug 03 22:42:14 I think andres proposal is the way to go. Altough I'd somehow like to change the proposal 3 to something like 6 month or so. Aug 03 22:42:20 I mean, we have a history and we don't need to hide it :) Aug 03 22:42:58 well torkiano. If the maintainers close all the bugs, the informatino is already gone :) Aug 03 22:43:38 muelli: I think that what andre was trying to say is that they will only answerwhen you close the bug, so you're just delaying the answer 6 months :p Aug 03 22:43:41 if we have NEEDINFO for 6 weeks after "is this still an issue in current GNOME", i'd also propose 6 weeks here. Aug 03 22:43:46 * seb128 has left (Remote closed the connection) Aug 03 22:43:52 Susana, true that :) Aug 03 22:44:10 hehe Aug 03 22:44:17 andre, +1 Aug 03 22:45:04 so yeah, Susana, would you like to find out the debian-gnome address (simple though) so that one of us can write them (FWIW I could do that)? We then write to the maintainers personally CCing bugsquad, right? Aug 03 22:45:45 muelli: sure Aug 03 22:45:47 oh, and let's close them with a keyword like obsolete-module-2009 or so. Aug 03 22:46:44 so, hm. If I understood that correctly, we have a couple of mails to write :) Can we compile a list of OBSOLETE modules? The email address of the maintainers should be "$module"-maint@gnome.org Aug 03 22:46:57 muelli, no, I do not know of any (sorry for the delay, discussing an issue with my customer) Aug 03 22:48:05 And once we have a list, we need a text to write. So if you have time to write such a text please speak up :) Aug 03 22:48:45 (oh crap, laggy network in here) Aug 03 22:48:57 muelli, where can I search a list of obsolete modules? Aug 03 22:49:43 torkiano: good question. I don't dare to answer. Andre should now, as he's in release team Aug 03 22:50:39 so ACTION: torkiano to compile a list of obsolete modules ready for our next meeting. Probably with the help of andre ;-) Aug 03 22:50:44 * andre reads backlog Aug 03 22:50:51 ah. sure :) Aug 03 22:50:57 ok ;) Aug 03 22:51:08 see subpages of http://live.gnome.org/TwoPointTwentyseven/ Aug 03 22:51:12 it's all public ;-) Aug 03 22:51:17 * muelli thinks that IRC is still too asynchronous... Aug 03 22:51:28 but i do know that some libgnome bugs still get fixed for example Aug 03 22:51:33 We can create a wiki page with the status of the "contact" Aug 03 22:51:43 while gnome-vfs does not get fixes. hence another reason why to contact maintainers first Aug 03 22:51:56 torkiano, what contact? Aug 03 22:52:05 so next ACTION is andre to write up a text to the maintainers ready for next meeting. Agreed? Aug 03 22:52:10 * fizz has left (Leaving.) Aug 03 22:52:17 ok Aug 03 22:52:37 We can then split up the mailing to the maintainers next meeting... Maybe coordinate that with some downstream distros. Aug 03 22:52:47 andre, a list of deprecated modules and if we hace a response or not and what is the response Aug 03 22:52:49 i presume the deprecated list here: http://bugzilla.gnome.org/enter_bug.cgi is not updated :/ Aug 03 22:52:58 * fizz (~fizz@ip-81-210-151-47.unitymediagroup.de) has joined #bugs Aug 03 22:52:59 no, it's not updated Aug 03 22:53:09 ACTION for Susana: Update the list in Bugzilla ;-) :D Aug 03 22:53:34 but in release-team i only know about officially included stuff. there's a huge list of modules in bugzilla that probably are not worked on anymore Aug 03 22:53:48 e.g. i closed update-manager or scaffold bugs a few weeks ago Aug 03 22:53:54 scaffold saw it's lat release 6 years ago. Aug 03 22:54:01 :D Aug 03 22:54:06 that's stuff you can find out by taking a look at the FTP server Aug 03 22:54:18 hence it's not only me who can come up with a list ;-)) Aug 03 22:54:39 muelli: ok Aug 03 22:54:50 I still don't think it's a really good idea to close these bugs. I mean we need to at least think about people taking the code and working on it... Aug 03 22:54:52 I'll search the ftp for older modules Aug 03 22:55:21 and I'll put it in a wiki page for discussion Aug 03 22:55:26 * mbarnes has left (Ping timeout: 600 seconds) Aug 03 22:55:56 * pterjan (~pterjan@cmoi.fasmz.org) has joined #bugs Aug 03 22:57:06 since we're not reaching a consensus i propose we discuss this on the list for more opinions Aug 03 22:57:10 so andre: will you write a text to be send to the maintainers? Like "Hey hey, are you still maitaining the module $foo and are you interested in it's bugs being open? You haven't been included in GNOME for a long time and we'd like to have the bugs closed because Andre thinks it's aestatically unpleasent to have your bugs open" ... ;-) Aug 03 22:57:25 It's totally fine if you don't take the job, just want to know... :) Aug 03 22:58:49 yeah Susana. Could be discussed on bugsquad-list. then we have at least one topic to discuss about.... *thinking* Aug 03 23:00:02 muelli, everybody can take a look for such modules, and everybody can send such a text and CC bugsquad Aug 03 23:00:10 i don't think it's a dedicated action just for me :) Aug 03 23:00:17 * lajjr has left (Read error: 131 (Connection reset by peer)) Aug 03 23:00:28 i can do that for some modules, others can do it for others i'd say :) Aug 03 23:00:38 it's simply that i don't want to block anybody who has more time than i have Aug 03 23:00:45 sure andre. But we need to have at least one text to send ;-) Aug 03 23:01:26 ah. ok. ACTION: andre: come up with sexy "if ya ain't maintaining that module anymore, can i eat it?" email text Aug 03 23:01:50 yeah, I totally understand. I feel that you are the right one to come up with a simple example, probably by sending a mail to a maitainer and CCing bugsquad, because you know how to talk with with these "maintainers" ;-) Aug 03 23:02:00 yeah, awesome. Aug 03 23:02:41 I can make a table with maintainers of old modules, so we can have a complete list Aug 03 23:02:55 or do you think is not necessary? Aug 03 23:02:57 awesome torkiano. Aug 03 23:03:16 and, may I suggest, we add it the result of the contact with them (close/do not touch) Aug 03 23:03:18 torkiano: I want to have such a list, even if it already exists ;-) Aug 03 23:03:30 hggdh: +1 Aug 03 23:03:40 * seb128 (~seb128@89.127.177.75) has joined #bugs Aug 03 23:03:50 k Aug 03 23:04:13 I think we should discuss next actions on that topic during our next meeting. Deciding the keyword to add when closing bugs... Aug 03 23:04:14 hggdh, +1 Aug 03 23:04:24 iirc phomes and me one worked on a list of dead modules in svn... Aug 03 23:04:48 http://live.gnome.org/ThomasAndersen/CvsCleanup Aug 03 23:04:58 could be a nice starting place for a list of rotten modules Aug 03 23:05:32 * rego has left (Leaving) Aug 03 23:05:36 * mbarnes (~mbarnes@nat-pool-rdu.redhat.com) has joined #bugs Aug 03 23:06:01 okay guys. I'm sorry but my concentration is fading away. I either need to have a break or we discuss the very final steps like who compiles a protocol, follows up on bugsquad-list and kicks poeple to do their tasks... Aug 03 23:06:12 can we quickly handle next topics? Aug 03 23:06:15 * andre getting a bit tired, and there's beer and substances waiting in the kitchen Aug 03 23:06:26 * hggdh fixes on 'beer' Aug 03 23:07:01 * muelli gets himself another beer while they do the penalty kicking in soccer... Aug 03 23:08:29 muelli, who's broadcasted? Aug 03 23:08:39 andre: HSV vs. Duesseldorf... Aug 03 23:08:49 haha, ok Aug 03 23:09:08 So may I propose to get that meeting to an end? (as just a bunch of people are still with us :( ) Aug 03 23:09:13 +1 Aug 03 23:10:15 and i want to say thanks to torkiano for pushing to have a meeting and coming up with issues. great work man! :) Aug 03 23:10:23 Yes, me too. Aug 03 23:10:29 andre, ;) Aug 03 23:10:31 Really, thank you very much dude! Aug 03 23:10:44 It's really good to see some action going on! :) Aug 03 23:10:47 yes Aug 03 23:10:53 I'm going to upudate all the wiki pages I can Aug 03 23:11:14 So what I want is a summary sent to bugsquad-list and uploaded to the wiki somewhere beneath bugsquad/meeting. Aug 03 23:11:32 also I want people to be kicked so that they do their jobs ;-) Aug 03 23:11:40 so we need to schedule the next meeting to discuss the rest of the points Aug 03 23:11:46 When is the next bugsquad meeting? Aug 03 23:11:49 :) Aug 03 23:12:03 i'd propose same place, same time in a month Aug 03 23:12:14 let's not decide that here, because the pople who couldn't make it today can't raise their voice Aug 03 23:12:28 yes Aug 03 23:12:36 let's have someone wrting to bugsquad-list and creating a doodle to determine the next meeting Aug 03 23:12:42 one month or 15 days ? Aug 03 23:12:46 one month Aug 03 23:12:56 there will be no progress in 2 weeks, i tell you Aug 03 23:13:01 ACTION: muelli: come up with a new meeting doodle for next month' meeting Aug 03 23:13:17 andre, :) Aug 03 23:13:59 who's going to write a summary, following up on bugquad-list and uploading it to the wiki? (I can probably do that if anybody sends me a backlog). Aug 03 23:14:08 http://live.gnome.org/Bugsquad/DeprecatedModules Aug 03 23:14:11 (but it'll probably take a week) Aug 03 23:14:46 i can send a backlog, maybe i find also time for it earlier, don't know yet :) Aug 03 23:14:54 DrBob: Still have an hour of paid RedHat time to write up a summary, upload everything and write to bugsquad-list? Aug 03 23:15:15 muelli: I don't think that's for me to say Aug 03 23:15:38 * muelli whispers to andre: HSV hat gewonnen :) Aug 03 23:15:58 muelli, damnit! :-P Aug 03 23:16:13 well DrBob, as a Bugsuqad member, you are :) But you don't have to of course. And if you don't feel ready^tm it's not an issue at all. Aug 03 23:16:41 so, okay, as I've said: I can do it, but it takes me at least a week due to holidays and everything. Aug 03 23:17:06 muelli, I'm going to update http://live.gnome.org/JavierJardon/Bugsquad with the things discussed here Aug 03 23:17:57 muelli: I can do it if you want, enjoy your vacations Aug 03 23:18:03 * baptistemm has left (« Beam me up Scotty ») Aug 03 23:18:36 woahr Susana, that'd be great :) I didn't ask you directly because I felt that you have enough stuff to do already :) Aug 03 23:18:59 i'll simply post the unedited log to bugsquad list, okay? Aug 03 23:19:19 so awesome, we have Susana and torkiano writing a protocol, summarising the points we've discussed and it's solutions as well as listing the actions... Aug 03 23:19:42 andre: oh no, that'd be a pain to read. I think torkiano and Susana will do a great job summarizing everything :) Aug 03 23:19:52 okay :) Aug 03 23:20:36 andre: but you can poke the poeple and check whether they'll do their jobs :) Aug 03 23:21:07 ok I'll do that in the next days and check with torkiano Aug 03 23:21:08 hehe Aug 03 23:21:15 thanks everybody for the nice meeting! Aug 03 23:21:30 I for myself, could need a reminder of the jobs I've taken (no backlog...) Aug 03 23:21:43 k, do we have everything? Are we set? Aug 03 23:21:44 * mkanat has left (Read error: 104 (Connection reset by peer)) Aug 03 23:22:11 * mkanat (~mkanat@c-67-188-1-39.hsd1.ca.comcast.net) has joined #bugs Aug 03 23:22:19 muelli: we'll include ACTIONS in the summary, don't worry Aug 03 23:22:20 I feel we're pretty good. Thank you guys for your attention and patience. Aug 03 23:22:21 ok Susana, I ping you when I updated the wiki page. Aug 03 23:22:46 thank you all :) Aug 03 23:23:23 torkiano: i'd like to add http://live.gnome.org/GettingTraces/ApplicationSpecificInstructions to the wiki page for discussion in the next meeting Aug 03 23:23:33 if you don't mind Aug 03 23:23:36 FWIW and not necessarily for the record: I'm muelli@jabber.ccc.de if anybody wants to add me on his/her jabber roster. I think it's quite nice to have some GNOMEy contacts... Aug 03 23:23:52 Susana, of course, feel free to add anything you want Aug 03 23:24:38 okay, I think the one who has opened the meeting should "officially" close it now.. ;-) Aug 03 23:24:45 * fizz has left (Leaving.) Aug 03 23:25:47 torkiano, !! ^^ ;-) Aug 03 23:25:56 aps :), thank you all for coming, see you next month ;)