[22:44] <grundleborg> winterz: we can get quite a lot of manpower, as long as coding skills aren't required
[22:44] <winterz> +grundleborg: yes. I'd like to see a kdepim regression testing
[22:44] <winterz> +grundleborg: basically, see what worked in 3.5.9 but doesn't in 4.x
[22:45] <winterz> +grundleborg: and bug squashing would be nice too
[22:45] <winterz> +grundleborg: we have a severe lack of bug reports for the devel version.. and I can't believe we are doing that well :)
[22:45] <grundleborg> winterz: it sounds like you need something a bit more urgent than bugzilla triage at the moment though... but just regression testing sounds feasable
[22:46] <winterz> +grundleborg: that would be great
[22:46] <vkrause> +winterz: btw, if you are aware of critical bugs in primary applications, please let till, ervin, me or anyone else of kdab know, we need to fix those anyway
[22:46] <winterz> +vkrause,grundleborg: we have a list of regressions on techbase.
[22:46] <winterz> +that list needs to be updated
[22:47] <grundleborg> winterz: ok, so the idea is to just get people to try and trigger bugs in the various apps, and then stick them in bugzilla against "SVN" version of the app?
[22:48] <winterz> +the url is ...http://techbase.kde.org/Projects/PIM/KDE_4-related_bugs
[22:48] <winterz> +grundleborg: yep. either that or maybe put them on the techbase page. sorta like we did for the kde4 krush days
[22:49] <grundleborg> oh OK, that'll be much more efficient
[22:49] <winterz> +yea, I like that idea
[22:49] <grundleborg> winterz: if you have any tips/advice about how to do this kind of testing, it would be very useful :)
[22:50] <winterz> +grundleborg: that's part of the problem. few people have access to a kolab or groupware resource. for example.
[22:51] <vkrause> +winterz: the still open stuff on that lists doesn't look too critical to me, ie. not affecting the basic functionality in most cases, still anoying though, sure
[22:52] <winterz> +gotta go for a bit. be back pretty soon
[22:52] <grundleborg> winterz: we can probably schedule a day on this for 2.5 weeks time, does that sound OK?
[20:53] <tmcguire> +grundleborg: yes, it is a good idea. I think blauzahl already talked to me about that.
[20:54] <grundleborg> tmcguire: winterz was saying yesterday that perhaps it would be helpful to have a krush day on KDEpim - ie looking for regressions
[20:54] <grundleborg> do you think KMail is in need of that, or should we focus on cleaning up bugzilla
[20:55] <tmcguire> +Well, personally I know tons of regressions of KMail, but I think users will certainly find more, so a krush day would be nice.
[20:56] <tmcguire> +I didn't have time to fix all the regressions of KMail yet.
[20:56] <tmcguire> +But if important ones are found, that'd be good.
[20:57] <tmcguire> +I don't know what best to focus on - both regression finding and bugzilla cleaning is important
[20:57] <grundleborg> tmcguire: perhaps regression finding in the immediate future in light of the worries about kdepim being ready for 4.1
[20:58] <grundleborg> tmcguire: are there any particular areas of KMail where you would suggest we focus our efforts?
[20:58] <tmcguire> +yes, ok. Although the worries of KDEPIM are not of finding regressions, it's more that not enough people are fixing them. But again, for KMail I'd still like that.
[20:59] <tmcguire> +grundleborg: nothing specific. regressions crept in in all places of kmail due to the porting.
[20:59] <tmcguire> +tmcguire: I probably only noticed regressions in the areas i'm using myself, so testing advanced/rarly used stuff would be good
[21:00] <tmcguire> +argh. I always talk to myself...
[21:00] --> nixeagle has joined this channel (n=eagle@unaffiliated/nixeagle).
[21:01] <grundleborg> tmcguire: well, we will have an army of people who can help with this, but will not necessarily have much experience with KMail, so blauzahl and I and others will try and produce some guides before hand about how to carry out this kind of testing
[21:02] <tmcguire> +personally, I think best way to find regressions is by just using it (for POP3, you can enable "leave messages on server" if you are using kmail3 normally and want to have some test data)
[21:02] <tmcguire> +each user has different usage pattern, and some are very untested at the moment I guess
[21:04] <grundleborg> tmcguire: and would it be more useful for us to file bugzilla reports, or just list all regressions on a techbase page somewhere?
[21:05] <tmcguire> +grundleborg: bugzilla would be useful. there are not many kde4 bugs reported there yet, so for me it is easy to have an overview
[21:05] <grundleborg> tmcguire: well, if we use that, then we will tag them all aswell to enable easy searching ([krush] or something)
[21:05] <tmcguire> +grundleborg: there is also a bit outdated list at http://techbase.kde.org/Projects/kdepim/kde4bugs#KMail, but that is mainly for myself.
[21:06] <tmcguire> +that link also has a link to a bugzilla query for KDE4 regressions/bugs in kmail, very useful
[21:07] <tmcguire> +grundleborg: I'll sync that techbase list with my local list here before the bug day, so you guys can have an overview of known regressions
[21:08] <grundleborg> tmcguire: we're thinking of Sunday 18th May, as that would keep the fortnightly bug-day timetable going - gives us enough time to clean up and set up the next between, but keeps momentum going
[21:09] <tmcguire> +I'm away for large parts of the day on that sunday (kart race of the company)
[21:09] <tmcguire> +But if you can do without me, that would be ok
[21:10] <grundleborg> tmcguire: I think it would be much better to do it with you. when would be better?
[21:10] <grundleborg> we could do a saturday, or move it back/forward a week
[21:10] <tmcguire> +move it back/forward a week, saturday is also bad for me (same reason)
[21:10] <grundleborg> how about 11th May then?
[21:11] <tmcguire> +sounds fine
[21:12] <tmcguire> +How many people participate in such a bug day? I didn't follow the konqueror bug day at all, since I'm not a konq dev
[21:12] <grundleborg> tmcguire: we've had about 20 people actively triaging.
