On 15.09.2021 18:27, Erich Steinböck wrote: > > "silence counts as approval" > > Rony, my silence is never consent, please stop suggesting that.I just didn't > get around to answering.
Being on a few open-source projects there is one concept (from the Apache Software Foundation, ASF) that is very helpful, called "lazy consensus". This is what I have been trying to excercise in this project in order to help further the project. "Lazy consensus" works as long as no one objects, hence it is important to leave enough time for everyone to consider (usually three days in the ASF, but I took at least a week in this project knowing that many are under time/resource pressure, in this case even more time). As you may have seen, I would not commit anything once an objection gets raised. However, it would be important to clarify objections over time (e.g. I still would be very interested in your test-case and your thoughts about the suggested changes of the json class, which is based on the current ooRexx json class) in order to resolve them, if that is possible at all. The "Apache way" is subsumized in [1], the Apache rules are here [2], "lazy consensus" is used a lot. Above all is a constructive attitude assumed and respect for each other, which leads to (sometimes surprising) principles like "community over code". > > concurrency trace > > I'm in favor of the concurrency trace feature request, but I dislike the > suggested use of an > environment variable. I'd rather use a new ::option directive subkeyword like > ::option trace > concurrent, or maybe a new trace prefix, like trace !r. Better ideas highly > welcome. > Also I'd prefer a more compact representation (less white space). Then I'm > not sure why we'd > trace activation numbers or about the "reserve" concept. They allow insights in concurrently traced code, e.g. in the case of lock-ups, or seeing how ooRexx works when e.g. a reply gets executed, etc. It will be rarely the case that concurrency trace will get run (only when debugging concurrently running programs in order to understand them or to debug problems in concurrently executing programs), but if needed, as much as insight as possible will be of great help for the programmer. (I remember quite many occasions in the past years when debugging multi-threading issues between ooRexx and Java where I would have saved literally months - and evenings and weekends - if concurrency trace with this information had been available back then.) ---rony [1] "Briefing: The Apache Way": <http://www.apache.org/theapacheway/> [2] "How the ASF works": <http://www.apache.org/foundation/how-it-works.html>
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
