FWIW, I have applied the suggested changes for everybody to see and comment on: https://hpx.stellar-group.org/governance/
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: Simberg Mikael <[email protected]> Sent: Friday, June 4, 2021 7:28 AM To: [email protected]; [email protected] Subject: Re: [hpx-pmc] [Proposal for VOTE] Proposal to split HPX into at least two repositories +1 On this matter I won't wait the 72 hours though... If there are no more comments by tonight I'll send out the vote. _____ From: Hartmut Kaiser <[email protected] <mailto:[email protected]> > Sent: Friday, June 4, 2021 2:04:13 PM To: Simberg Mikael; [email protected] <mailto:[email protected]> Subject: RE: [hpx-pmc] [Proposal for VOTE] Proposal to split HPX into at least two repositories +1 to both suggestions (type of vote and change to governance document) ;) 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: Simberg Mikael <[email protected] <mailto:[email protected]> > Sent: Friday, June 4, 2021 2:34 AM To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [hpx-pmc] [Proposal for VOTE] Proposal to split HPX into at least two repositories I revised the message based on Hartmut's feedback and have it ready to go modulo one thing which I think I also forgot for the previous pragma once vote: what type of vote we're doing. I hope we can choose the type of vote without a vote... Pasting the types of votes here: - Lazy consensus: An action with lazy consensus is implicitly allowed, unless a binding -1 vote is received. Depending on the type of action, a vote will then be called. Note that even though a binding -1 is required to prevent the action, all community members are encouraged to cast a -1 vote with supporting argument. Committers are expected to evaluate the argument and, if necessary, support it with a binding -1. - Lazy majority: A lazy majority vote requires more binding +1 votes than binding -1 votes. Responses will be collected after 72 hours. - Consensus approval: Consensus approval requires three binding +1 votes and no binding -1 votes. Responses will be collected after 72 hours. - Unanimous consensus: All of the binding votes that are cast are to be +1 and there can be no binding vetoes (-1). Responses will be collected after 120 hours. - 2/3 majority: Some strategic actions require a 2/3 majority of PMC members; in addition, 2/3 of the binding votes cast must be +1. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product). Responses will be collected after 120 hours. I suggest Concensus approval majority as binding -1's are quite serious (i.e. opposition from the PMC), but I think +/-0's should not break the vote. 2/3 majority is also an option. With our current setup that would actually require a +1 from 4 out of 5 PMC members. Somewhat related to this vote, I would like to change the wording in the governance document to say "Responses will be collected after a minimum of X hours." 72 hours is far to short at least for this particular vote and changing the wording like that would just give us the freedom to choose the appropriate time depending on the vote. Mikael _____ From: Simberg Mikael Sent: Tuesday, June 1, 2021 11:31:14 AM To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [hpx-pmc] [Proposal for VOTE] Proposal to split HPX into at least two repositories Thanks Hartmut. Yes, that's a good idea! Will do that. The deadline for the vote was somewhat arbitrary. When I wrote this yesterday it meant almost two weeks of voting time, ending at the next HPX meeting. I don't mind extending it a bit though, especially as I'd be happy to hear if e.g. Thomas or Adrian have any comments before sending it out. Mikael _____ From: Hartmut Kaiser <[email protected] <mailto:[email protected]> > Sent: Tuesday, June 1, 2021 2:55:49 AM To: Simberg Mikael; [email protected] <mailto:[email protected]> Subject: RE: [hpx-pmc] [Proposal for VOTE] Proposal to split HPX into at least two repositories Mikael, Thanks for putting this together. This looks good to me. May I suggest that you separate the two parts of this into their own emails when sending it to the HPX lists? 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] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Simberg Mikael Sent: Monday, May 31, 2021 8:22 AM To: [email protected] <mailto:[email protected]> Subject: [hpx-pmc] [Proposal for VOTE] Proposal to split HPX into at least two repositories Hi all, We discussed in the last PMC meeting again the possibility of splitting HPX into one or more repositories, but concluded that we and the community should vote on it before making any decisions. I would like to send the following email to the hpx-users and hpx-devel mailing lists. I've attempted to keep the message as neutral as possible, with the exception for my own vote at the end where I explain why I and the other CSCS developers support the proposal. Please let me know if you'd like to have anything anything changed, added, or removed. --- begin message --- 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 again want to consult the community through a vote. My personal vote and motivation for the change is at the bottom of the 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 remain in the current STEllAR-GROUP/hpx 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. As a reminder, voting works as follows: 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) Responses from developers and users alike are encouraged. Please vote as soon as possible, but we will leave the voting open until Thursday 10th June. My own vote is +1, for the following reasons: - Local-only HPX already contains a huge amount of functionality useful for many people and making it a separate project gives it more visibility outside of "HPX is a library for distributed computing"; it makes it explicit for potentially curious users that HPX is useful even when one is not interested in distributed computing. This may bring in new users and developers. - Build times of HPX itself for local-only users will be reduced, without additional configuration. - There is no chance of accidentally including distributed headers that may slow down builds for local-only users; a local-only user has to explicitly opt-in to using distributed features of HPX. - Importantly, for users of distributed HPX there is no additional effort if they are using a package manager. For those who build HPX manually there is at most one additional project to configure and build. This can be zero additional projects if using git submodules or CMake's fetchcontent. Names of headers, functionality, and libraries that currently expose distributed functionality will continue to do so under the same names (modulo refactoring that might be done even if the project stayed in one repository) and will require no adaptations for users of distributed HPX. - Development - Testing and development can be done more quickly, not having to build and run over 1000 tests (the split is roughly a third each for local-only non-parallel-algorithm tests, local-only parallel-algorithm tests, and distributed tests). This makes testing everything locally before opening pull requests more feasible, and gives faster feedback through CI. - In cases where it seems awkward or annoying to do changes across two repositories I believe it's a sign that the two projects are too tightly coupled and that coupling needs to be addressed. However, I think these cases will be few (or are already resolved). Simple changes like renamings can easily be done in two stages across two repositories. - Releases can be made independently and more frequently with two or more smaller projects. My personal preference would be to split HPX even further such that it e.g. futures/senders/receivers would only be interfaces available as a separate library. This may encourage alternative runtimes to be implemented and used behind the standards-conforming interfaces, without having to depend on and build the HPX runtime. The same goes for the parallel algorithms. In general, I think providing smaller (within reason) reusable libraries can encourage use of and contribution to those libraries in a way that a large monolithic project can't. It also encourages separation of concerns (I'm not arguing that this can't be done in a monolithic project, but accidentally introducing unwanted coupling between separately developed libraries is very difficult). However, for the purposes of this vote, this finer split is not on the table. CSCS has unfortunately decided not to continue to support the full distributed version of HPX long term, and will therefore be withdrawing development of HPX in its current form after the next HPX release. We hope to continue working with the HPX community as part of a reduced hpx-local project and will continue to maintain and develop modules that are part of that reduced project. Kind regards, Mikael Simberg --- end message --- Mikael
_______________________________________________ hpx-pmc mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-pmc
