Re: [Chicken-hackers] Regarding #1564: srfi-18: (mutex-unlock) Internal scheduler error

[Peter Bex]

On Mon, Dec 03, 2018 at 10:46:38AM +0100, Jörg F. Wittenberger wrote:
> Whats going on here IMHO is that a lot of lifetime, your guys and mine, is
> wasted. At the same time the code quality of the result is likely worse that
> what I'm using as the source to cut out those patches. [...]
> 
> So for me the question remains: wouldn't it be much, much more efficient to
> work sort-of hand-in-hand with one of the core developers, or maybe on the
> list to get the remaining things (bugs and improvements) fixed and reviewed?

I think this would be quite helpful.  Perhaps at another hackathon we can
sit down together (ideally with more than one core developer to ensure we
all are on the same page and understand it).

This is one of the ugly truths of open source collaborative development;
you really have to have a good plan on how to communicate the changes
you're making back to "upstream", or face porting nightmares every time
you upgrade.  I've made this mistake a few times too back in the day,
some with CHICKEN (the Makefile refactor is one of those) and some with
other projects.

Dropping a complex patch is generally not the way to go about adding code
to an existing system.  On the other hand, sometimes one person or group
creates such large changes that can't be split up (for instance the
numbers stuff, or the chicken-install rewrite).  At such points there is
no realistic way to review everything, so the best the "upstream" can do
is test the code extensively and eyeball it for obvious mistakes and
other quality issues.

This also means that the submitted code has to be so simple that others
who aren't familiar with it can study it and debug it if issues crop up
(and they will, with any sizable change).  The scheduler is a major pain
point regarding this, since concurrency is difficult enough (or
impossible?) to understand at all, regardless of the quality of the code
in the scheduler (which isn't stellar to begin with).

So at some point, merging a large change is a bit of an act of faith.
It also requires trust, which needs to be built up over time by showing
consistent quality patches and commitment to the project.  This is the
really hard bit, especially if you just want one specific feature to be
added and don't have that many other things to contribute to the system
simply because it works for you.

I don't have a good solution for this, but your suggestion to walk
through the code together seems like a good one to me.

Cheers,
Peter

signature.asc
Description: PGP signature