Hartmut, I know I promised this already last eek, and that you're now on holidays. If you don't happen to have the time to have a look at this properly until you're back, so be it. Let's get this right instead of rushing it out. That is to say, enjoy your holidays!
________________________________ From: Simberg Mikael Sent: Monday, August 9, 2021 11:12 To: [email protected] Subject: Request for feedback on "Statement on intent to split HPX into multiple independently developed libraries" Hi all, We've discussed in the biweekly meetings that we should release a statement on what we intend to do after the vote last month (i.e. to go forward with the proposal). I've prepared some text that we can publish on the mailing list and blog. However, I'd be grateful if you'd be willing to read through the statement to 1. see if you even agree with the statement, and 2. suggest changes if needed. Note, I've written it from the perspective of the PMC as a whole, since we as a whole voted in favour of the proposal. If any of you are not comfortable with that we can change it to only include specific names. ------ Statement on intent to split HPX into multiple independently developed libraries In July the HPX project management committee (PMC) proposed to split HPX into two or more separate libraries, with separate repositories. There was a vote on the topic on the hpx-users mailing list (https://www.mail-archive.com/[email protected]/msg00134.html). Four out of five PMC members voted +1 (agree with the proposal and willing to help to realize it), and one voted +0 (agree with the proposal). Of the non-PMC members voting, five voted -1 and two voted +1. With these results the PMC has nonetheless decided to move forward with the proposal. Since this is contrary to what many of the non-PMC members voted, we believe this requires some explanation to avoid confusion about the next steps. Regardless of the exact details of how HPX will be split: - HPX as the name, project, and repository will continue to refer to the top-level project which includes local and distributed functionality. - The developers at CSCS focused on local-only HPX will continue to attend the same mailing lists, IRC channels, and biweekly meetings with other HPX developers. The separation into separate libraries makes responsibilities of maintenance more explicit, but the overall development will still be done together with other developers as before. The users voting against the proposal raised some concerns. We'd like address them below. - "Not enough motivation to keep developing the distributed parts": Splitting the repository will not affect the the available manpower to develop distributed functionalities. CSCS's involvement in developing distributed HPX has been mainly related to maintenance, and CSCS will continue to provide e.g. continuous integration resources to the full HPX project and will continue to coordinate larger changes with the rest of the development team. If the fate of distributed HPX rested solely on CSCS's involvement it would speak of a larger problem. Luckily that is not the case, as there is interest from other institutions who we hope will be able to fill the gaps and go further than CSCS's involvement in HPX so far. - "Test coverage will suffer": Test coverage will remain the same, though there may be delays in fixing bugs in lower level libraries that affect higher level libraries. On the other hand, lower level libraries can be developed without being immediately held up by changes required to the higher level libraries. Automated testing will be critical for this to work. Higher level libraries should be tested against both stable and unstable versions of the lower level libraries to catch API breaks and bugs. - "Maintaining similar APIs for local and distributed will be more difficult": This is mainly a function of design discussions and reviews, not the libraries being in the same repository. Local-only HPX developers may still review changes in distributed features, when useful. Additionally, distributed features will still be built on top of local features when possible, just as now. - "We need a release strategy and product manager for each library": Yes, releases will need to be coordinated (though not necessary released simultaneously) and this can be done as part of our current biweekly meetings. Part of the motivation for CSCS to propose the split is to move some of the responsibility of release management to others. This will of course initially be a larger burden for other developers, but CSCS intends to support them in the process. In addition, the release procedure for HPX has already been streamlined, and once a developer is familiar with the procedure it can be done relatively easily. Finally, the main burden of creating a release is not in the technical work, but in deciding what features to merge, when to prepare a release, and communicating the changes in a release. These are all things that the CSCS developers are in any case ill-equipped to do well for distributed functionality. We will proceed with the proposal in small steps, allowing us to back out should any unresolvable issues arise. Importantly, we want this to impact existing users of distributed HPX as little as possible. That means that as the first step we will continue to adjust the actual split of libraries within the current HPX repository. Once that is done, we will proceed to release at least one version of HPX with one or more libraries split out into separate repositories, but the top-level HPX repository still being the only way to consume HPX. Once that has been completed, continuous integration has been set up for all the sub-projects, issue tracking and release plans are set up we will start developing the separate libraries more independently. We hope that this clears at least some of the concerns regarding the split. If there are unanswered or new concerns we'd be happy to hear them and respond to them. ----- Mikael
_______________________________________________ hpx-pmc mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-pmc
