As mentioned during the call yesterday, I have stopped making contributions for the time being to HPX. It's a kind of informal strike.
"Don't let the perfect be the enemy of the good" When I start a protest march against open source coding practices, I will put that quote on my banner. I do not wish to spend weeks working on some improvement, only to have a PR rejected because "it fixes this and this and this, but you have not also fixed that..." If the review process points out some new bug that code will introduce, an API inconsistency (like for example the use of an executor for an MPI function dispatch), a problem that isn't obvious but might be exposed by the PR, then I have no problem with the PR collecting comments and sitting un-merged pending further work (and will reluctantly do it). But I do not want to waste my time fixing other problem in HPX for a PR that does solve the problem it targets. I believe the correct procedure that we should adopt is that if a PR is good enough to fix a problem, but could benefit from some additional work, then the PR should be accepted with the proviso that an issue should also be created to indicate what extra work has been suggested. I'm sure I'll be back on HPX in a few weeks and then I will again look at my PRs. I still have many plans for things to implement. JB
_______________________________________________ hpx-pmc mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-pmc
