This is a quick wrap-up entry for Plasma Bug Days which was held over the last two days. First, we accomplished a lot. I mean a lot. The first goal was to drop into third place on the Weekly Bug Report. We accomplished that on the first day and so moved onto another goal suggested by one of the participants: have fewer reports open than we did six months ago. We also accomplished that. Now we have a new goal: break 1000. We're just 120 reports away from that goal right now.
Today has been relatively slow going as it isn't an official Bug Day so just a few showed up to do bug triage today. Quite promisingly, though, some people from the Bug Days showed up today again. I do hope all of them continue to be involved and help with the bug wrangling as their efforts were just fantastic this weekend.
I also set about to fix some of the older and more annoying issues in some of the more commonly used parts of Plasma Desktop. Many commits later, and many already-fixed (along with some won't or can't fixes, too), and the bug report count has dropped yet further. 4.8 is going to be a fantastic release.
Yesterday was really invigorating, as well: even more people showed up for day 2 than for day 1. That's understandable as it was the weekend. Together we mowed through large quantities of bug reports.
We also pulled together some Plasma bug hunting documentation for newcomers. It was very clear that handing out bugzilla account upgrades to those who took the time to show up was really worthwhile as well: it empowered people who may not have otherwise asked to help out, and boy did they ever.
I used to host bug days sem-regularly, but with project growth and life business they fell to the wayside. I'm happy to say, though, that bug days will be a regular part of Plasma life again, with at least one such event hosted every release cycle.
Our long term goal is to get down to a stable 400-500 open defect reports, and I think that is achievable. We have worked through 600 reports in just 2 weeks, over half of them just this weekend. So it is possible.
The results of a clean bug database are that it becomes far, far easier for developers to identify what needs attention. It also helps our involved users know that, yes, we still have a pulse and do care and pay attention, something that sometimes gets missed.
I now have a nice parcel of "junior job" bugs and a handful of "critical issues for 4.8" in hand as a result of Bug Days ... and a really good feeling about things to boot.
Subscribe to:
Post Comments (Atom)
11 comments:
And that's the kind of news about KDE I love to read! :) Congrats to everybody and hope this will be repeated more often, great initiative people!
Full agree! Awesome what such coordinated focus of efforts can achieve! :-)
Great news to read!
I wish i could have joined but sadly my weekend was full with traveling -_-
It would be nice to see a blog post with the bugs that are critical that are going to be fixed because of the bug days.. Just out of interest :)
Hey Aaron,
Is it a necessity to a a currenkt plasma install or can I also use a live system to test for plasma bugs? I would like to test a current Plasma version like 4.7.3 or a beta in a VM.
@markg85: i'll be dropping a mail to plasma-devel :) i'd rather not blog about fixes that are yet to be made after all (for fear of disapointing if they don't get addressed)
@burke: testing a live install or in a VM is perfectly valid. at least one of the bug days participants was running 4.8beta1 in a VM, in fact :)
Aaron,
Porting KDE 4.8 beta1 to OpenBSD...
I feel that plasma-addons was rushed for beta 1, too many build failures which were not addressed before beta 1, forcing to get patches from git :(
Please atleast run a full clean build before tagging.
thanks
I was enjoying my first bug day.
Hopefully i can do again in next bug day.
Here's what I learned:
-Lots of things and options about plasma. Using it daily in one fixed configuration is completely different than trying random configuration when trying to reproduce a specific bug. I may change my workflow a bit after seeing a few things that I like.
-Bug triaging takes a lot of time if you do it properly. Even closing an old bug report may take a few minutes, to at least check that it's gone.
-Wishlist items in bugzilla are quite useless, just because of their sheer number. With developers already busy with what they have in mind, there is no way one of them would go on buzilla looking for the next idea. Try it yourself: go to bugzilla ans sort the bugs by severity. That's almost half of them wishes!.
-I now sort of know how to look at a backtrace, and how to generate one. I even managed to run gdb (though with much difficulties).
-I had not gone on IRC for years. Good to know that old habits were buried very deeply (although it might be a bit worrying for my wife :) ). Tried Konversation, have now to try Quassel.
All in all, that was quite enjoyable and a very rewarding experience. Being granted the privileges Aaron referred to helped a lot (I honestly don't think I would have stuck around that much, if I had to constantly refer to some sort of chaperone).
I'll probably come back for more soon :)
I'd love reading a summary of the fixes so far, to better appreciate what went into 4.8 (I'm a changelog junkie, just look at Konvi's :).
I was working in 4.7.3 + VM 4.8b1, that worked perfectly fine... I hope to do some more in the near future.
600 open bugs would be awesome (but feasible, I think). Given 1500 bugs per release cycle, it suggests that the average lifetime of a bug is then much less than 1 release. Surely this would include many duplicate/invalids with very short life times, but still: each version x.y.4 might be quite a lot closer to 'bugfree' in that way!
I wonder, is the maintainability of 600 open bugs so much easier that the devs could keep up, or will these cleanup sessions always be necessary?
@Claude: While I agree that the wishlist right now is kind of useless, it shouldn't be in the long run. But since wishes usually have a longer life time, they do require more care and maintenance. And 1100 wishes is definitely something that needs to be thinned out :)
@Thijs: "Given 1500 bugs per release cycle, it suggests that the average lifetime of a bug is then much less than 1 release."
good observation, and a pretty impressive number.
"is the maintainability of 600 open bugs so much easier that the devs could keep up, or will these cleanup sessions always be necessary?"
it depends in part on whether or not we can keep up with regular triage duties. if not, then the reports will pile up over a release and we'll need to do such sessions regularly. so we rely in part on people helping us stay on top of those 1500+ reports per cycle.
the other factor is that we tend to get more reports during releases, which is to be expected. this can be a release of a distro, a pre-release (alpha/beta/rc) or a full upstream release. so it isn't a steady trickle of reports but times when the flow is higher than at other times.
short answer: the devs need continued help to keep on top of things. a q/a and bug triage team are invaluable assets that compliment the coding work.
Post a Comment