# networking bugs and bugme.osdl.org (fwd) - Thread: https://externals.io/message/2918 - Original archive: https://news-web.php.net/php.internals/2918 - Started by Sascha Schumann on 2003-06-28T01:22:25+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #2918 — Sascha Schumann — 2003-06-28T01:22:25+00:00 URL: https://externals.io/message/2918#2918 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 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 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. --- ## #3072 — John Coggeshall — 2003-06-28T08:58:00+00:00 URL: https://externals.io/message/2918#3072 · In reply to: #2918 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/ -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~ --- ## #2940 — Jani Taskinen — 2003-06-28T13:45:43+00:00 URL: https://externals.io/message/2918#2940 · In reply to: #2918 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 >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 > 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. > > > -- https://www.paypal.com/xclick/business=sniper@php.net&no_note=1&tax=0¤cy_code=EUR --- ## #2941 — Sascha Schumann — 2003-06-28T13:56:47+00:00 URL: https://externals.io/message/2918#2941 · In reply to: #2940 > > 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 --- ## #2943 — Rasmus Lerdorf — 2003-06-28T14:02:45+00:00 URL: https://externals.io/message/2918#2943 · In reply to: #2941 > > > > […] > > 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 --- ## #2944 — Jani Taskinen — 2003-06-28T14:06:28+00:00 URL: https://externals.io/message/2918#2944 · In reply to: #2941 > > > > […] > > 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 --- ## #2945 — Sascha Schumann — 2003-06-28T14:43:17+00:00 URL: https://externals.io/message/2918#2945 · In reply to: #2944 > 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- 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 --- ## #2946 — Jani Taskinen — 2003-06-28T14:55:43+00:00 URL: https://externals.io/message/2918#2946 · In reply to: #2945 > > […] > > 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- 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. > > […] > > 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 --- ## #2947 — Sascha Schumann — 2003-06-28T15:32:53+00:00 URL: https://externals.io/message/2918#2947 · In reply to: #2946 > 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 --- ## #2948 — Jani Taskinen — 2003-06-28T15:57:11+00:00 URL: https://externals.io/message/2918#2948 · In reply to: #2947 > > […] > > 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 --- ## #3076 — Sascha Schumann — 2003-07-01T10:25:11+00:00 URL: https://externals.io/message/2918#3076 · In reply to: #3072 > 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 --- ## #3077 — Derick Rethans — 2003-07-01T10:27:05+00:00 URL: https://externals.io/message/2918#3077 · In reply to: #3076 > > > > […] > > 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/ --- ## #3078 — Wez Furlong — 2003-07-01T10:29:09+00:00 URL: https://externals.io/message/2918#3078 · In reply to: #3077 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" To: "Sascha Schumann" Cc: "John Coggeshall" ; Sent: Tuesday, July 01, 2003 11:27 AM Subject: Re: [PHP-DEV] [PATCH] SQLite session storage > > > > […] To > > […] > > 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. --- ## #3079 — Sascha Schumann — 2003-07-01T10:29:29+00:00 URL: https://externals.io/message/2918#3079 · In reply to: #3077 > > > > […] > > 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 --- ## #3080 — John Coggeshall — 2003-07-01T10:51:24+00:00 URL: https://externals.io/message/2918#3080 · In reply to: #3078 > 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/ -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~