Everything

php

Re: networking bugs and bugme.osdl.org (fwd)

php.internals

Sascha Schumann

23 years ago

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.

Jani Taskinen

23 years ago

And the point was..? AFAICT, our system works fine.
Seemed like the linux dudes are way behind. :)

--Jani

On Sat, 28 Jun 2003, Sascha Schumann wrote:

>    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.
>
>
>

--
https://www.paypal.com/xclick/business=sniper@php.net&no_note=1&tax=0&currency_code=EUR

Sascha Schumann

23 years ago

On Sat, 28 Jun 2003, Jani Taskinen wrote:

>
>     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

Rasmus Lerdorf

23 years ago

On Sat, 28 Jun 2003, Sascha Schumann wrote:

> On Sat, 28 Jun 2003, Jani Taskinen wrote:
>
> >
> >     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

Jani Taskinen

23 years ago

On Sat, 28 Jun 2003, Sascha Schumann wrote:

>On Sat, 28 Jun 2003, Jani Taskinen wrote:
>
>>
>>     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

Sascha Schumann

23 years ago

>     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

Jani Taskinen

23 years ago

On Sat, 28 Jun 2003, Sascha Schumann wrote:

>>     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

Sascha Schumann

23 years ago

>     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

Jani Taskinen

23 years ago

On Sat, 28 Jun 2003, Sascha Schumann wrote:

>>     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

Andi Gutmans

23 years ago

It might be a good idea to assign responsibilities to people. For example,
the XML extension author would only get his bug reports and so on.

Andi

Sascha Schumann

23 years ago

On Sat, 28 Jun 2003, Andi Gutmans wrote:

> It might be a good idea to assign responsibilities to people. For example,
> the XML extension author would only get his bug reports and so on.

That's the idea behind bugs-<SECTION> mailing lists (also
accessible through nntp).  People who are interested are free
to subscribe.

- Sascha

Andi Gutmans

23 years ago

At 06:15 PM 28/6/2003 +0200, Sascha Schumann wrote:

>On Sat, 28 Jun 2003, Andi Gutmans wrote:
>
> > It might be a good idea to assign responsibilities to people. For example,
> > the XML extension author would only get his bug reports and so on.
>
>     That's the idea behind bugs-<SECTION> mailing lists (also
>     accessible through nntp).  People who are interested are free
>     to subscribe.

We should force maintainers to subscribe to their sections :)

Andi

Pierre-Alain Joye

23 years ago

On Sat, 28 Jun 2003 19:37:54 +0200
Andi Gutmans <andi@zend.com> wrote:

> We should force maintainers to subscribe to their sections :)

This is what I plan for bugs.pear :-)

pierre

Jani Taskinen

23 years ago

On Sat, 28 Jun 2003, Andi Gutmans wrote:

>At 06:15 PM 28/6/2003 +0200, Sascha Schumann wrote:
>>On Sat, 28 Jun 2003, Andi Gutmans wrote:
>>
>> > It might be a good idea to assign responsibilities to people. For example,
>> > the XML extension author would only get his bug reports and so on.
>>
>>     That's the idea behind bugs-<SECTION> mailing lists (also
>>     accessible through nntp).  People who are interested are free
>>     to subscribe.
>
>We should force maintainers to subscribe to their sections :)

There are now several new headers in the bug emails:

X-PHP-Version
X-PHP-Category
X-PHP-OS
X-PHP-Status
X-PHP-Old-Status

Now you can filter out whatever you want a lot easier.
(for example I have now two folders, one for PHP 4 bugs and one for PHP 5)

--Jani

John Coggeshall

23 years ago

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/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

Sascha Schumann

23 years ago

On Sat, 28 Jun 2003, John Coggeshall wrote:

> 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

Derick Rethans

23 years ago

On Tue, 1 Jul 2003, Sascha Schumann wrote:

> On Sat, 28 Jun 2003, John Coggeshall wrote:
>
> > 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/
-------------------------------------------------------------------------

Wez Furlong

23 years ago

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

> On Tue, 1 Jul 2003, Sascha Schumann wrote:
>
> > On Sat, 28 Jun 2003, John Coggeshall wrote:
> >
> > > 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

John Coggeshall

23 years ago

On Tue, 2003-07-01 at 06:29, Wez Furlong wrote:

> 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/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

Sascha Schumann

23 years ago

On Tue, 1 Jul 2003, Derick Rethans wrote:

> On Tue, 1 Jul 2003, Sascha Schumann wrote:
>
> > On Sat, 28 Jun 2003, John Coggeshall wrote:
> >
> > > 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