Fork me on GitHub

Thanks @sogaiu! I think if he does not respond maybe he does not want to respond. Which is his choice, of course. I was thinking of reaching out to past heavy committers, but then decided that might be trying a bit too hard. I really don’t want to bother him if he does not want to be bothered.


yes, that makes sense, though afaiu we don't know whether he is just not seeing these messages as you suggested earlier. i was thinking in general though that life being what it is, no matter what library, at some point original maintainers might want to be involved less or not at all -- but from the perspective of folks who use a library, some idea of what a transition might be like upfront before starting to use a library may come to be more of an issue in the times to come (am reminded a bit of code-of-conduct docs). since there are already many projects without clear statements of this sort, i thought that as a community, having some discussion about whether or how such things might be helped might be in order.


Thanks @sogaiu, I value your ideas and opinions. I think there is a chance my email might have ended up in his spam folder, but there is much less of a chance that he will miss the git issue I raised. For me, this is sufficient effort. I’ll let the git issue sit for a month before taking any action. For contacting original authors of inactive repos in general, I think a reasonable effort should made while still respecting that person’s choice not to respond. I suppose defining what a reasonable effort might be could be helpful for clj-commons? For me for rewrite-clj: active on Slack? no -> email -> response after over a month? no -> git issue -> response after 1 month? we’ll see, but if no, I think that’s good enough and will make a choice.

👍 4

that sounds reasonable to me. i know though that it's possible there are situations and viewpoints i haven't considered and that's where some open discussion might be helpful. well, my suspicion is that this is likely to become more of an issue in the coming times (and i suspect there are others who have already thought about this). there is no hurry i suppose to try to discuss such things 🙂 at any rate, really appreciate your efforts on the rewrite-clj* front!


@lee oh yeah, thanks for the rewrite-cljs performance tuning link -- had not seen that before!


Interesting huh? With all the performance tuning done in cljs since that article was written, I wonder if their impact is the same. Cljs has a built in simple-benchmark that might help in getting some answers.


would comparing the results from the developer tools profiler with cljs + rewrite-cljs from the time the article was written with recent versions of cljs + rewrite-cljs be straight-forward?


btw, you mentioned working on cljs a bit -- have you already looked at lumo?


I think comparing rewrite-cljs optimizations with my rewrite-cljc (or whatever it becomes named) unoptimizations should be doable. It is on my todo to look at but I won’t block an alpha release for that. I have not looked at lumo at all yet! Looking forward to doing so someday.


oh darn it, i thought you were looking to become a lumo maintainer 🙂


ha! so many opportunities to learn and explore!