Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: [hpx-users] [VOTE] Proposal to split HPX into at least
two smaller projects and repositories (Thomas Heller)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Jun 2021 19:09:53 +0200
From: Thomas Heller <[email protected]>
Subject: Re: [hpx-devel] [hpx-users] [VOTE] Proposal to split HPX into
at least two smaller projects and repositories
To: Hartmut Kaiser <[email protected]>,
[email protected]
Cc: [email protected]
Message-ID:
<cajcxaexz0phajwxdbknzvw_fxm9tpk1uqhftqfdsgcn0s0a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20210616/503ac611/attachment.html
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 72, Issue 10
*****************************************
