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
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers