Re: How to share knowledge about known bugs?

[Jörg F. Wittenberger]

see towards the end of the message, what I men with "block lists":

I mean some piece of (shared) machine readable source code listing the
limitations, or rather the attribute.  Like '(thread-safe yes) maybe
even as part of the egg file (the license is already there, which would
allow to filter for, say, "GPL compatible" or "GPL free").

It's a lot of work to figure all these things out of either source
or documentation.  The idea: maybe we can somehow share the results.

Best

Jörg

Am Wed, 01 Dec 2021 21:23:21 +0100
schrieb Mario Domenech Goulart <mario@parenteses.org>:

> Hi Jörg and all,
> 
> On Wed, 1 Dec 2021 10:30:44 +0100 "Jörg F. Wittenberger"
> <Joerg.Wittenberger@softeyes.net> wrote:
> 
> > one in a while I wonder how to handle a list of eggs not suitable
> > for certain situations due to some undocumented internals.  
> 
> I think a first step would be removing the "un" prefix from
> "undocumented". :-)
> 
> > Examples like "egg used global variables" vs. "application uses egg
> > from multiple threads" come to mind.
> >
> > Or the case with the "synch" egg, which, last time I checked,
> > combined dynamic-wind and mutex use in a flawed way defeating the
> > locking purpose.[1]
> >
> > So far I don't have a good idea how this could be dealt with.  Guess
> > some kind of configurable/selectable blocklist would be in order.
> > After all global variables are OK if you know there is only one
> > thread or you know about them and ensure proper locking.
> >
> > Important I'd find that the lists and reason of listing should be
> > shared somehow.  After all this is about learning undocumented
> > things/facts/risks.  
> 
> Usually we have sections in egg documentation about assumptions, known
> bugs, limitations, caveats etc.  The documentation is in our wiki.
> Everyone can make contributions to improve the quality of egg
> documentation, including mentioning caveats.
> 
> Ideally bugs should be fixed, of course.  When they are discovered,
> they should be at least reported (e.g., https://bugs.call-cc.org or
> whatever issue tracker egg authors use).
> 
> I'm not completely sure I understand what you mean by "block list".  I
> think the best we can do is document issues, really, and leave it up
> to users to decide whether the issues are relevant for their use
> cases or not.
> 
> All the best.
> Mario