Dear all,
I think there are several (at least three) aspects to this issue that require consideration. I will comment on each of the aspects first as this is important to understand my vote on the issue. a) Impact on our users Splitting the repository into two or more separate projects does not have to have any impact on users. We would be able to make it work either way, i.e. we can easily make it look like one project for users of the whole functionality based on several repositories (cmake fetch_content or even git subprojects come to mind). However, we could also make it look like several smaller projects, even if all of the code lives in one repository. For this reason, I think the user aspect is not relevant in deciding whether to split up the repository or not. b) Impact on our developers The impact on developers is not as clear-cut. Developers interested in contributing to the local part of HPX would benefit from a split for reasons outlined below by Mikael. OTOH, developers working on the parts that have been separated out (presumably parallel algorithms and friends, and distributed functionalities) would have to invest more time and effort in order to keep everything consistent. Splitting might also have a negative effect on the code quality of the individual sub-projects as the overall testing coverage would be reduced. Also, it might increase the overall turnaround time necessary for fixing problems accidentally introduced in the core project. This is caused by a) the reduced testing coverage, and b) by the separation in time of the testing cycles on the different projects. The responsibility for diagnosing (and possibly fixing) errors introduced in the core project may now shift to the developers of the dependent projects (in case the local tests all pass but dependent projects start breaking). Overall, a split of repositories lessens the workload of some of the developers (currently mostly CSCS) and increases the workload for others (currently mostly LSU). Such a split may also negatively impact code quality. A split of repositories may impose a barrier to developers that wish to contribute to the depending projects as the amount of effort needed for this would be larger than necessary. c) Impact on our collaboration For me, this aspect is most important as a split of repositories without the consent of everyone involved would be prone to negatively impacting our collaboration. Our teams have been very successful in working on HPX together for a long time now. All teams have had considerable impact on the project as a whole and have invested a lot of time and resources - without that we wouldn't have been able to build a basis for our respective future projects and plans. It would be a shame to risk this successful collaboration and the mutual benefits resulting from it in the future. The fact that the CSCS leadership wishes to separate the core libraries is a confirmation that they see significant value in using HPX in their future projects. The quality and stability of our collaboration is not determined by the amount of differences in interests our teams have. It is determined by whether we are able to find mutually acceptable compromises and go ahead together. I'm willing to contribute my share of compromises and would expect so from the CSCS team as well. Finally, my vote: while from a distance and based on LSU's interests I should clearly vote -1, I will not oppose the proposal and will help with it's implementation - if the community wishes to go for it. However, I would prefer leaving everything in one repository and rather help creating a build system infrastructure (and related tooling) that allows for developers to only work on the parts they are interested in. If we decided to perform the split, I would hope that this process will not negatively influence any of our users and that the community we have built over the years will evolve further in the future. The mutual and overall benefits will hopefully outweigh the additional work we will have to invest. Also, in this case I would be in favor of creating three sub-projects: hpx-core, hpx-parallelism, and hpx-distributed. Thanks! Regards Hartmut --------------- <https://stellar.cct.lsu.edu> https://stellar.cct.lsu.edu <https://github.com/STEllAR-GROUP/hpx> https://github.com/STEllAR-GROUP/hpx From: [email protected] <[email protected]> On Behalf Of Simberg Mikael Sent: Monday, June 7, 2021 2:53 PM To: [email protected]; [email protected] Subject: [hpx-users] [VOTE] Proposal to split HPX into at least two smaller projects and repositories 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/> 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
