There is a thread on the netdev mailing list right now
regarding bug databases. Lots of interesting points, some of
them apply to the PHP project as well.
Head of thread:
http://marc.theaimsgroup.com/?l=linux-netdev&m=105669326002116&w=2
- Sascha
---------- Forwarded message ----------
Date: Fri, 27 Jun 2003 17:19:33 -0700 (PDT)
From: David S. Miller davem@redhat.com
To: alan@lxorguk.ukuu.org.uk
Cc: greearb@candelatech.com, mbligh@aracnet.com, linux-kernel@vger.kernel.org,
linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: networking bugs and bugme.osdl.org
From: Alan Cox alan@lxorguk.ukuu.org.uk
Date: 28 Jun 2003 00:04:30 +0100
it means you can spot patterns, trends
I already spot patterns and trends when people retransmit the
bug/patch/whatever. As do other people.
Frankly, people who aren't willing to maintain their patches
and retransmit them to me, do not matter as far as I am concerned.
If you don't want to put forth the effort, I do not want to interact
with you. I feel the same way about bugs.
Linus has been saying this and doing it for years, and I've had to
learn the hard way that he's absolutely right in this regard. If you
try to track everything, you accomplish nothing. You will, however,
get overloaded and frustrated. To scale one must reserve the right to
hit the delete key and it's GONE not accumulating somewhere else.
We need social engineering. If someone never gets their bug looked at
because they post absolute crap bug reports, that's a feature. If
people spend all this effort making sense of such reports and fix them
ANYWAYS the reporter will never learn to produce high quality bug
reports that are more useful to us. That means the scarcest resource
we have is being used inefficiently.
That same goes for patches, and I've watched over time how this works.
This is another reasone that I hate when people privately email me
stuff, because I WILL delete it and I WILL lose it. If you post
it to the lists, it gets accumulated somewhere but it doesn't clog
my mailbox and it doesn't create a backlog for me. It also means that
if I'm sipping Mai Tai's in Hawaii other people will see and can react
to the report.
Since SQLite will be bundled in the future, I sat down and got
acquainted with it by writing a module for the session extension which
allows users to store their session data in a SQLite database*.
To use, just apply the patch to session.c (which adds the reference to
the new module and adds the mod_sqlite.c to config.m4) and compile.. To
use it set session.save_handler = sqlite.
comments welcome.
John
- =
--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~
Since SQLite will be bundled in the future, I sat down and got
acquainted with it by writing a module for the session extension which
allows users to store their session data in a SQLite database*.To use, just apply the patch to session.c (which adds the reference to
the new module and adds the mod_sqlite.c to config.m4) and compile.. To
use it set session.save_handler = sqlite.
Sounds fine in principle. Where is the patch?
- Sascha
Since SQLite will be bundled in the future, I sat down and got
acquainted with it by writing a module for the session extension which
allows users to store their session data in a SQLite database*.To use, just apply the patch to session.c (which adds the reference to
the new module and adds the mod_sqlite.c to config.m4) and compile.. To
use it set session.save_handler = sqlite.Sounds fine in principle. Where is the patch?
Wouldn't it be much nicer to put this in the sqlite extension instead
because people may turn sqlite support off? php_register_session_module
should be used here IMO.
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
Hey John,
Mail me the patch and I'll look at integrating it into the sqlite extension
itself; as Derick says, it is probably the best place for it.
--Wez.
----- Original Message -----
From: "Derick Rethans" derick@php.net
To: "Sascha Schumann" sascha@schumann.cx
Cc: "John Coggeshall" john@coggeshall.org; internals@lists.php.net
Sent: Tuesday, July 01, 2003 11:27 AM
Subject: Re: [PHP-DEV] [PATCH] SQLite session storage
Since SQLite will be bundled in the future, I sat down and got
acquainted with it by writing a module for the session extension which
allows users to store their session data in a SQLite database*.To use, just apply the patch to session.c (which adds the reference to
the new module and adds the mod_sqlite.c to config.m4) and compile..
To
use it set session.save_handler = sqlite.Sounds fine in principle. Where is the patch?Wouldn't it be much nicer to put this in the sqlite extension instead
because people may turn sqlite support off? php_register_session_module
should be used here IMO.
Hey John,
Mail me the patch and I'll look at integrating it into the sqlite extension
itself; as Derick says, it is probably the best place for it.
http://www.coggeshall.org/php/mod_sqlite.tar.gz
I missed rolling the mini-patch I had for session.c in the tarball,
which doesn't matter if you are integrating into ext/sqlite... but if
your curious
http://www.coggeshall.org/php/session.c.patch
John
--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~
Since SQLite will be bundled in the future, I sat down and got
acquainted with it by writing a module for the session extension which
allows users to store their session data in a SQLite database*.To use, just apply the patch to session.c (which adds the reference to
the new module and adds the mod_sqlite.c to config.m4) and compile.. To
use it set session.save_handler = sqlite.Sounds fine in principle. Where is the patch?Wouldn't it be much nicer to put this in the sqlite extension instead
because people may turn sqlite support off? php_register_session_module
should be used here IMO.
Yes, "principle" referred to having a sqlite-enabled storage
container in the base distribution. The implementation
should be self-contained, of course.
- Sascha
And the point was..? AFAICT, our system works fine.
Seemed like the linux dudes are way behind. :)
--Jani
There is a thread on the netdev mailing list right now
regarding bug databases. Lots of interesting points, some of
them apply to the PHP project as well.Head of thread:
http://marc.theaimsgroup.com/?l=linux-netdev&m=105669326002116&w=2
- Sascha
---------- Forwarded message ----------
Date: Fri, 27 Jun 2003 17:19:33 -0700 (PDT)
From: David S. Miller davem@redhat.com
To: alan@lxorguk.ukuu.org.uk
Cc: greearb@candelatech.com, mbligh@aracnet.com, linux-kernel@vger.kernel.org,
linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: networking bugs and bugme.osdl.orgFrom: Alan Cox alan@lxorguk.ukuu.org.uk
Date: 28 Jun 2003 00:04:30 +0100it means you can spot patterns, trends
I already spot patterns and trends when people retransmit the
bug/patch/whatever. As do other people.Frankly, people who aren't willing to maintain their patches
and retransmit them to me, do not matter as far as I am concerned.
If you don't want to put forth the effort, I do not want to interact
with you. I feel the same way about bugs.Linus has been saying this and doing it for years, and I've had to
learn the hard way that he's absolutely right in this regard. If you
try to track everything, you accomplish nothing. You will, however,
get overloaded and frustrated. To scale one must reserve the right to
hit the delete key and it's GONE not accumulating somewhere else.We need social engineering. If someone never gets their bug looked at
because they post absolute crap bug reports, that's a feature. If
people spend all this effort making sense of such reports and fix them
ANYWAYS the reporter will never learn to produce high quality bug
reports that are more useful to us. That means the scarcest resource
we have is being used inefficiently.That same goes for patches, and I've watched over time how this works.
This is another reasone that I hate when people privately email me
stuff, because I WILL delete it and I WILL lose it. If you post
it to the lists, it gets accumulated somewhere but it doesn't clog
my mailbox and it doesn't create a backlog for me. It also means that
if I'm sipping Mai Tai's in Hawaii other people will see and can react
to the report.
--
https://www.paypal.com/xclick/business=sniper@php.net&no_note=1&tax=0¤cy_code=EUR
And the point was..? AFAICT, our system works fine. Seemed like the linux dudes are way behind. :)
Count the developers who regularly access the bug db.
Contrast that number to the overall number of C developers.
Notice how the bug db effectively is ignored by the vast
majority of developers.
- Sascha
And the point was..? AFAICT, our system works fine. Seemed like the linux dudes are way behind. :)Count the developers who regularly access the bug db. Contrast that number to the overall number of C developers. Notice how the bug db effectively is ignored by the vast majority of developers.
Count the number of developers who regularly write documentation for their
code. Contrast that with the overall number of C developers. Notice how
documentation is effectively ignored by the vast majority of developers.
I don't think you can make neither debugging luser problems nor writing
documentation attractive to the average developer through any sort of
superficial interface or process change.
-Rasmus
And the point was..? AFAICT, our system works fine. Seemed like the linux dudes are way behind. :)Count the developers who regularly access the bug db.
Contrast that number to the overall number of C developers.
Notice how the bug db effectively is ignored by the vast
majority of developers.
I think I get now what you're after and I already am thinking
of some ways to improve this. This mail has some nice ideas we could
adopt:
http://marc.theaimsgroup.com/?l=linux-netdev&m=105675444021250&w=2
Especially the "screening" part, we already do that by setting
bugs we can verify. It might be a good idea to make a list
of those, instead of just all the "open" reports and send that
to internals@lists.php.net. I bet most, if not all, just delete
that current summary that gets send every now and then. :)
We could also dedicate some categories to the maintainers of that
extension/part of PHP and send a summary of open reports in them
to the maintainer..?
--Jani
I think I get now what you're after and I already am thinking of some ways to improve this. This mail has some nice ideas we could adopt:
These points are interesting from my pov as a lazy developer.
(a) make bug reports automatically vanish after some time
(eliminates luser reports)
(b) screen bug reports and put them into second db
(c) post a single notice to bugs-<CATEGORY> once per screened
bug report
(d) provide email/nntp interface
Especially the "screening" part, we already do that by setting bugs we can verify. It might be a good idea to make a list of those, instead of just all the "open" reports and send that to internals@lists.php.net. I bet most, if not all, just delete that current summary that gets send every now and then. :)
I always ignore/delete summaries and the stupid reminders..
- Sascha
I think I get now what you're after and I already am thinking of some ways to improve this. This mail has some nice ideas we could adopt:These points are interesting from my pov as a lazy developer.
(a) make bug reports automatically vanish after some time
(eliminates luser reports)
Yup, I took that on my TODO already. :)
(b) screen bug reports and put them into second db
That's done already. ("Verified" bugs). I don't think there's
need for a second database.
(c) post a single notice to bugs-<CATEGORY> once per screened
bug report
That's also in my TODO, I was planning to add some more headers
to the mails to make it possible to filter them locally.
(per category, status, etc).
(d) provide email/nntp interface
Any ideas for the email interface?
We do have already some sort of email interface, there are urls
to certain quick-resolves in every email coming from the bug db
but I guess that's not what you want.
Especially the "screening" part, we already do that by setting bugs we can verify. It might be a good idea to make a list of those, instead of just all the "open" reports and send that to internals@lists.php.net. I bet most, if not all, just delete that current summary that gets send every now and then. :)I always ignore/delete summaries and the stupid reminders..
But if the summaries contain only screened (== verified) reports,
and sent one per category? Better ideas would be appreciated, of course.
--Jani
But if the summaries contain only screened (== verified) reports, and sent one per category? Better ideas would be appreciated, of course.
Well, I pretty much embrace the idea that reports ought to
fall through the cracks, if they don't bother developers
enough to address them. Otherwise, reports just accumulate
and accumulate without having any effect.
- Sascha
But if the summaries contain only screened (== verified) reports, and sent one per category? Better ideas would be appreciated, of course.Well, I pretty much embrace the idea that reports ought to
fall through the cracks, if they don't bother developers
enough to address them. Otherwise, reports just accumulate
and accumulate without having any effect.
Currently you don't get any mails from the reports unless someone
touches them. So they do 'fall through the cracks' already, sort of.
By adding the 'rotting' feature will make this a bit more effective.
Just thinking whether or not there should be a notification
for the submitter when a report rots. Comments?
Getting all the emails from php-bugs@lists.php.net is really
too much traffic, that's why I was thinking about adding some
headers to the mails to make it easier to filter out those you
really want to see.
Some short cut URLs would do this already though, using the
web interface and search..but it's not quite the same. :)
--Jani