- -1: ‘no,’ ‘disagree’. > justification for not addressing the issue Separating the fundamental distributed and local-only functionalities of HPX compromises the project's integrity over time, if not rapidly, for the obvious reason that there will not be enough motivation to keep both in working co simultaneously. This will exacerbate if they are maintained in separate repositories but is still a problem even if they are maintained in the same repository (e.g., HPX support for Vc, HPX examples repository, MiniGhost, HPXCL). That this interest exists is understandable because our excellent collaborators at the CSCS have had to invest significant time and resources to maintain the distributed functionalities of HPX, which, at least in the short term, has not been sufficiently rewarding. On the other hand, the problem will be the opposite if the distributed functionalities become the focus, which will not be ideal either.
Sincerely, Parsa Amini On Mon, Jun 7, 2021 at 2:53 PM Simberg Mikael <[email protected]> wrote: > Dear HPX users and developers, > > The HPX users and developers at CSCS (that includes myself) have expressed > an interest in separating the local-only and distributed functionality of > HPX into two separate projects and repositories. This is a contentious > topic, so before we do a large change like this we want to consult the > community through a vote. My personal vote and motivation for the change > will follow in a separate message. > > Practically speaking, the proposal is to move the on-node functionality of > HPX (this includes futures, algorithms, basic CUDA/HIP support, a > local-only runtime, and all the utilities required to support this) into a > separate repository. The remaining distributed functionality of HPX would > keep the hpx name, stay in the current repository, and it would gain one > new dependency, called (e.g.) hpx-local. Releases of hpx and hpx-local > would often be done together, but could be done independently of each > other. The aim is to affect current users of distributed features of HPX > as little as possible, while giving users of local-only features a project > that, by default, gives them only local functionality. If there's > consensus to go ahead with a split, we will also consider splitting HPX > into more than two projects. > > Voting works as follows (from https://hpx.stellar-group.org/governance/): > If a formal vote on a proposal is called (signaled simply by sending a > email with [VOTE] in the subject line), all participants on the HPX user’s > mailing list may express an opinion and vote. They do this by sending an > email in reply to the original [VOTE] email, with the following vote and > information: > > - +1: ‘yes’, ‘agree’: also willing to help bring about the proposed action > - +0: ‘yes’, ‘agree’: not willing or able to help bring about the proposed > action > - -0: ‘no’, ‘disagree’: but will not oppose the action’s going forward > - -1: ‘no’, ‘disagree’: opposes the action’s going forward and must > propose an alternative action to address the issue (or a justification for > not addressing the issue) > This is a "Concensus approval" vote (see governance document for details). > Responses from developers and *users* alike are encouraged. Please vote > as soon as possible, but we will leave the voting open until Thursday 17th > June. > > > Kind regards, > > Mikael Simberg > _______________________________________________ > hpx-users mailing list > [email protected] > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users >
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
