Dear all, Even though I haven't contributed much in the past two years, I'm voting +1. My main reasoning is that this will allow to keep CSCS on board, which I think should have a high priority.
Tests Hartmut Kaiser <[email protected]> schrieb am Mi., 16. Juni 2021, 13:59: > > > 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://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/): > > 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-devel mailing list > [email protected] > https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel >
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
