Обсуждение: Finding some bug statistics..
Do we have any published bug statistics? I'm looking for some numbers such as the ones found here: http://bugs.mysql.com/tide.php In particular, I'd like to find on a monthly basis, the number of bugs opened, and closed - preferably since some time in 2002. Any help is appreciated.... thanks -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com
Chander Ganesan wrote: > Do we have any published bug statistics? I'm looking for some numbers > such as the ones found here: > > http://bugs.mysql.com/tide.php > > In particular, I'd like to find on a monthly basis, the number of bugs > opened, and closed - preferably since some time in 2002. > > Any help is appreciated.... The closest I think you would get is the changelogs, which generally will discuss bugs that are found and fixed. Unfortunately it will be tough to know which bugs were found on the basis of development versus user reports. Joshua D. Drake > > thanks >
Joshua D. Drake wrote: > Chander Ganesan wrote: >> Do we have any published bug statistics? I'm looking for some >> numbers such as the ones found here: >> >> http://bugs.mysql.com/tide.php >> >> In particular, I'd like to find on a monthly basis, the number of >> bugs opened, and closed - preferably since some time in 2002. >> >> Any help is appreciated.... > > The closest I think you would get is the changelogs, which generally > will discuss bugs that are found and fixed. Unfortunately it will be > tough to know which bugs were found on the basis of development versus > user reports. > > Joshua D. Drake So there's no central "bug database" that tracks such issues? These kinds of statistics would likely be very useful in supporting statements that speak to the maturity of PostgreSQL as a project, one metric of which is the find/fix rate... -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com
Chander Ganesan wrote: > Joshua D. Drake wrote: >> Chander Ganesan wrote: >>> Do we have any published bug statistics? I'm looking for some >>> numbers such as the ones found here: >>> >>> http://bugs.mysql.com/tide.php >>> >>> In particular, I'd like to find on a monthly basis, the number of >>> bugs opened, and closed - preferably since some time in 2002. >>> >>> Any help is appreciated.... >> >> The closest I think you would get is the changelogs, which generally >> will discuss bugs that are found and fixed. Unfortunately it will be >> tough to know which bugs were found on the basis of development versus >> user reports. >> >> Joshua D. Drake > So there's no central "bug database" that tracks such issues? These > kinds of statistics would likely be very useful in supporting statements > that speak to the maturity of PostgreSQL as a project, one metric of > which is the find/fix rate... We don't have a bug tracker, thus there is nothing to gather statistics from. We have a web form that is really just a sequence in a database that generates a bug id, and then remails the whole form to pgsql-bugs. For discussions of why we don't have one, see about a billion mails in the archives over the past 10 years or so :-( //Magnus
Chander Ganesan wrote: >> Joshua D. Drake > So there's no central "bug database" that tracks such issues? These > kinds of statistics would likely be very useful in supporting statements > that speak to the maturity of PostgreSQL as a project, one metric of > which is the find/fix rate... > There is no central bug database. Joshua D. Drake
Magnus Hagander wrote: > > We don't have a bug tracker, thus there is nothing to gather statistics > from. We have a web form that is really just a sequence in a database > that generates a bug id, and then remails the whole form to pgsql-bugs. > > For discussions of why we don't have one, see about a billion mails in > the archives over the past 10 years or so :-( > The general policy is a 72 hour bug fix, right? Do we have any ideas/numbers as to the currently "open" number of bugs (identified but not fixed yet)? That would be just as useful in some regard. Also, is the sequence only a sequence, or is some of the data held in the database (queryable?) At the very least, I could probably get an idea of the bug submit rate by looking at the first bug of each month in the bugs archive (or are many of the "bugs" really SPAM)? thanks -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com
Chander Ganesan wrote: > Magnus Hagander wrote: >> >> We don't have a bug tracker, thus there is nothing to gather statistics >> from. We have a web form that is really just a sequence in a database >> that generates a bug id, and then remails the whole form to pgsql-bugs. >> >> For discussions of why we don't have one, see about a billion mails in >> the archives over the past 10 years or so :-( >> > The general policy is a 72 hour bug fix, right? Do we have any > ideas/numbers as to the currently "open" number of bugs (identified but > not fixed yet)? That would be just as useful in some regard. There will be nothing but guesses. I won't venture into making one myself :-) > Also, is the sequence only a sequence, or is some of the data held in > the database (queryable?) At the very least, I could probably get an > idea of the bug submit rate by looking at the first bug of each month in > the bugs archive (or are many of the "bugs" really SPAM)? No, nothing is stored in the database. Code is here: https://pgweb.postgresql.org/browser/trunk/portal/system/form/submitbug.php as you can see, the only db access is: $rs = $this->pg_query("SELECT nextval('bug_id_seq')"); //Magnus
Dave Page wrote: > On Tue, Sep 30, 2008 at 4:12 PM, Chander Ganesan <chander@otg-nc.com> wrote: > >> Magnus Hagander wrote: >> >>> We don't have a bug tracker, thus there is nothing to gather statistics >>> from. We have a web form that is really just a sequence in a database >>> that generates a bug id, and then remails the whole form to pgsql-bugs. >>> >>> For discussions of why we don't have one, see about a billion mails in >>> the archives over the past 10 years or so :-( >>> >>> >> The general policy is a 72 hour bug fix, right? >> > > There is no general policy that I'm aware of. > Ahh..I saw Josh Berkus's post here: http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/ Is it safe to say that 72 hours is pretty standard? >> Do we have any >> ideas/numbers as to the currently "open" number of bugs (identified but not >> fixed yet)? That would be just as useful in some regard. >> > > Nope. > > >> Also, is the sequence only a sequence, or is some of the data held in the >> database (queryable?) At the very least, I could probably get an idea of >> the bug submit rate by looking at the first bug of each month in the bugs >> archive (or are many of the "bugs" really SPAM)? >> > > It's literally just a sequence. And the messages do get moderated, so > some numbers will be lost as spam. > Darn :( I'm giving a MySQL vs. PostgreSQL talk in October, and was hoping to provide some statistical metrics that would allow apples-apples comparisons for product maturity. -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com
On Tue, Sep 30, 2008 at 4:12 PM, Chander Ganesan <chander@otg-nc.com> wrote: > Magnus Hagander wrote: >> >> We don't have a bug tracker, thus there is nothing to gather statistics >> from. We have a web form that is really just a sequence in a database >> that generates a bug id, and then remails the whole form to pgsql-bugs. >> >> For discussions of why we don't have one, see about a billion mails in >> the archives over the past 10 years or so :-( >> > > The general policy is a 72 hour bug fix, right? There is no general policy that I'm aware of. > Do we have any > ideas/numbers as to the currently "open" number of bugs (identified but not > fixed yet)? That would be just as useful in some regard. Nope. > Also, is the sequence only a sequence, or is some of the data held in the > database (queryable?) At the very least, I could probably get an idea of > the bug submit rate by looking at the first bug of each month in the bugs > archive (or are many of the "bugs" really SPAM)? It's literally just a sequence. And the messages do get moderated, so some numbers will be lost as spam. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Tue, Sep 30, 2008 at 4:21 PM, Chander Ganesan <chander@otg-nc.com> wrote: > > Ahh..I saw Josh Berkus's post here: > http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/ > > Is it safe to say that 72 hours is pretty standard? > Less usually. However some bug require more thought and planning, so occasionally there will be ones that can take longer to figure out and understand. They are often complex security issues. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Tue, Sep 30, 2008 at 4:26 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Sep 30, 2008 at 4:21 PM, Chander Ganesan <chander@otg-nc.com> wrote: >> >> Ahh..I saw Josh Berkus's post here: >> http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/ >> >> Is it safe to say that 72 hours is pretty standard? >> > > Less usually. However some bug require more thought and planning, so > occasionally there will be ones that can take longer to figure out and > understand. They are often complex security issues. I should also add, that thats one of the key reasons why we don't have a tracker - the bugs are so few and usually fixed quickly that we don't need to track them. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Chander Ganesan wrote: > Dave Page wrote: >> On Tue, Sep 30, 2008 at 4:12 PM, Chander Ganesan <chander@otg-nc.com> >> wrote: >> >>> Magnus Hagander wrote: http://www.mysql.com/why-mysql/quality/ http://www.postgresql.org/about/news.363 When coverity ran against MySQL they found 1 bug for every 4k lines of code. When coverity ran against PostgreSQL they found 1 bug for every 39k lines of code. Joshua D. Drake
Chander Ganesan wrote: > Magnus Hagander wrote: > > > > We don't have a bug tracker, thus there is nothing to gather statistics > > from. We have a web form that is really just a sequence in a database > > that generates a bug id, and then remails the whole form to pgsql-bugs. > > > > For discussions of why we don't have one, see about a billion mails in > > the archives over the past 10 years or so :-( > > > The general policy is a 72 hour bug fix, right? Do we have any > ideas/numbers as to the currently "open" number of bugs (identified but > not fixed yet)? That would be just as useful in some regard. As far as I am concerned, the TODO list has every known bug against CVS HEAD, with lots of feature requests in there too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Dave Page wrote: >> Also, is the sequence only a sequence, or is some of the data held in the >> database (queryable?) At the very least, I could probably get an idea of >> the bug submit rate by looking at the first bug of each month in the bugs >> archive (or are many of the "bugs" really SPAM)? >> > > It's literally just a sequence. And the messages do get moderated, so > some numbers will be lost as spam. > Wow. Looks like even if we look at just the sequence value, over the course of a year, the number of "bugs" (many of which might be documentation related, or "not a bug" bugs) submitted via the form is less than the number that MySQL gets in two months. chander
Chander Ganesan wrote: > Dave Page wrote: >>> Also, is the sequence only a sequence, or is some of the data held in >>> the >>> database (queryable?) At the very least, I could probably get an >>> idea of >>> the bug submit rate by looking at the first bug of each month in the >>> bugs >>> archive (or are many of the "bugs" really SPAM)? >>> >> >> It's literally just a sequence. And the messages do get moderated, so >> some numbers will be lost as spam. >> > Wow. Looks like even if we look at just the sequence value, over the > course of a year, the number of "bugs" (many of which might be > documentation related, or "not a bug" bugs) submitted via the form is > less than the number that MySQL gets in two months. Well, it's not a realistic metric. To be fair, we get a number of bug reports that do not come through that webform as well. So it really has on real bearing at all on how many bug reports there are. //Magnus
On Tue, Sep 30, 2008 at 07:55:32AM -0700, Joshua D. Drake wrote: > Chander Ganesan wrote: >> Do we have any published bug statistics? I'm looking for some >> numbers such as the ones found here: >> >> http://bugs.mysql.com/tide.php >> >> In particular, I'd like to find on a monthly basis, the number of >> bugs opened, and closed - preferably since some time in 2002. >> >> Any help is appreciated.... > > The closest I think you would get is the changelogs, which generally > will discuss bugs that are found and fixed. Unfortunately it will be > tough to know which bugs were found on the basis of development > versus user reports. Commit messages tend to include phrases like, "per gripe from Foo Bar," but they can be a little tedious to go through. Fortunately, there's an archive of them going back some time in the PostgreSQL Weekly News :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Chander Ganesan wrote: > Wow. Looks like even if we look at just the sequence value, over the > course of a year, the number of "bugs" (many of which might be > documentation related, or "not a bug" bugs) submitted via the form is > less than the number that MySQL gets in two months. The bottom line is, PostgreSQL doesn't really have a lot of known, open bugs. Sure there are things don't work ideally, even some cases of "don't do this", but they should all be documented. Bugs that do come up are usually fixed within a couple of days and pushed out as a new release within a couple of months. If you compare this to the sort of bugs in, say, the Linux kernel and perhaps MySQL, where you have a lot of cases of incorrect and unexplained behavior lying open forever, that doesn't happen a lot for PostgreSQL. Then again, you have to be fair in counting the bugs. MySQL releases are released with regular version numbers a long time before they are labeled "GA", but people still report bugs against those. If we assigned a bug number to every report of an intermediate problem in a development release, we would surely see much higher numbers as well. So a fairer metric might be comparing how many bugs have been reported in MySQL 5.0 and PostgreSQL 8.3 between general release and now and what the turnaround is on those.