Comments on: Bug fixing in Gentoo: How we are performing http://blog.hartwork.org/?p=647 Free Software and Music Fri, 10 Sep 2010 22:08:05 +0200 http://wordpress.org/?v=2.8.6 hourly 1 By: Smorg http://blog.hartwork.org/?p=647&cpage=1#comment-66758 Smorg Sat, 13 Mar 2010 03:32:12 +0000 http://blog.hartwork.org/?p=647#comment-66758 @Donnie: I also have a similar vague idea. As a user I feel it is hard to know when my bug is really a bug and when i'm just doing something stupid, which probably leads to bugs not being reported. This in combination with the fact that some piece of software that exists yet is not in portage doesn't necessarily constitute a "bug". It would be nice to have a separate system that is more of a state tracker than a database of bugs, thus keeping it separate. I want an organized display of the current state and version of every upstream program, even those that aren't in portage, and be able to contrast that with the current state of the portage tree. You could add tons of metadata about stability and the level of interest in writing/updating/maintaining certain ebuilds. This would be the ultimate to-do quick-reference list with the added benefit that not everything on the list is actually a bug so there's no need to feel like you're just bitching at the devs by reporting an issue without having the know-how to fix the problem. I'll probably have the knowledge to work on something like this after i've crammed my brain with xhtml & javascript this semester. @Donnie: I also have a similar vague idea. As a user I feel it is hard to know when my bug is really a bug and when i’m just doing something stupid, which probably leads to bugs not being reported. This in combination with the fact that some piece of software that exists yet is not in portage doesn’t necessarily constitute a “bug”. It would be nice to have a separate system that is more of a state tracker than a database of bugs, thus keeping it separate.

I want an organized display of the current state and version of every upstream program, even those that aren’t in portage, and be able to contrast that with the current state of the portage tree. You could add tons of metadata about stability and the level of interest in writing/updating/maintaining certain ebuilds. This would be the ultimate to-do quick-reference list with the added benefit that not everything on the list is actually a bug so there’s no need to feel like you’re just bitching at the devs by reporting an issue without having the know-how to fix the problem.

I’ll probably have the knowledge to work on something like this after i’ve crammed my brain with xhtml & javascript this semester.

]]> By: Links 7/3/2010: Deutsche Börse and Red Hat | Boycott Novell http://blog.hartwork.org/?p=647&cpage=1#comment-66632 Links 7/3/2010: Deutsche Börse and Red Hat | Boycott Novell Mon, 08 Mar 2010 00:38:19 +0000 http://blog.hartwork.org/?p=647#comment-66632 [...] Bug fixing in Gentoo: How we are performing 2010-03-07 While I am surprised how many bugs we fix each day I am also shocked that each month almost 70 bugs go on top of the current pile. [...] [...] Bug fixing in Gentoo: How we are performing 2010-03-07 While I am surprised how many bugs we fix each day I am also shocked that each month almost 70 bugs go on top of the current pile. [...]

]]> By: Donnie Berkholz http://blog.hartwork.org/?p=647&cpage=1#comment-66618 Donnie Berkholz Sun, 07 Mar 2010 18:32:24 +0000 http://blog.hartwork.org/?p=647#comment-66618 I have this vague idea of creating an overall Gentoo dashboard that shows the status of everything Gentoo, not just bugzilla. Things like commit rates, bugs fixed and opened, forum post, etc over time. I have this vague idea of creating an overall Gentoo dashboard that shows the status of everything Gentoo, not just bugzilla. Things like commit rates, bugs fixed and opened, forum post, etc over time.

]]> By: Dror http://blog.hartwork.org/?p=647&cpage=1#comment-66593 Dror Sun, 07 Mar 2010 10:44:57 +0000 http://blog.hartwork.org/?p=647#comment-66593 The GMN (and GWN) used to have detailed bugzilla statistics, the code for that should be available somewhere. Maybe you can use it, or base the GSOC project on it. Also, thanks for revitalizing the bugday :) It badly needs a boost to achieve its full potential. The GMN (and GWN) used to have detailed bugzilla statistics, the code for that should be available somewhere. Maybe you can use it, or base the GSOC project on it.

Also, thanks for revitalizing the bugday :)
It badly needs a boost to achieve its full potential.

]]>