Send hpx-devel mailing list submissions to
        hpx-devel@stellar-group.org

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
        hpx-devel-requ...@stellar-group.org

You can reach the person managing the list at
        hpx-devel-ow...@stellar-group.org

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 (Zahra Khatami)
   2. Re: [hpx-users] [VOTE] Proposal to split HPX into at least
      two smaller projects and repositories (Gregor Daiss)


----------------------------------------------------------------------

Message: 1
Date: Wed, 16 Jun 2021 10:10:37 -0700
From: Zahra Khatami <z.khatam...@gmail.com>
Subject: Re: [hpx-devel] [hpx-users] [VOTE] Proposal to split HPX into
        at least two smaller projects and repositories
To: hpx-us...@stellar-group.org
Cc: "hpx-devel@stellar-group.org" <hpx-devel@stellar-group.org>
Message-ID:
        <cak-fqjaxckuqhx85zvpab5t2fvawal7vku-_shyhz2qxwbu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I am not very happy with the decision of splitting HPX. Consistency is an
important factor for us. Are we going to have a seperate release on each
project? If there is a common bug between different platforms, we need to
plan a release strategy to address it so as not to break a build on the
other platforms. This doesn't seem to be simple and needs a product manager
on each platform to monitor each release. I guess this plan will distract
us from development to other not-that-important issues.

Best Regards,

*Zahra Khatami* | Senior Compiler Engineer - HPC
NVIDIA


On Wed, Jun 16, 2021 at 7:49 AM Nanmiao Wu <wnan...@lsu.edu> wrote:

> - -1: ?no,? ?disagree?.
>
> I think splitting HPX to local and distributed ones would make developers
> more difficult to make things consistent.
>
> Best,
> Nanmiao
> ------------------------------
> *From:* hpx-users-boun...@stellar-group.org <
> hpx-users-boun...@stellar-group.org> on behalf of Weile Wei <ww...@lsu.edu
> >
> *Sent:* Wednesday, June 16, 2021 8:31 AM
> *To:* hpx-us...@stellar-group.org <hpx-us...@stellar-group.org>
> *Cc:* hpx-devel@stellar-group.org <hpx-devel@stellar-group.org>
> *Subject:* Re: [hpx-users] [VOTE] Proposal to split HPX into at least two
> smaller projects and repositories
>
>
> - -1: ?no,? ?disagree?.
>
>
>
> I believe splitting the HPX to local and distributed cases will impact the
> test coverage, which is fundamentally important to a scalable software
> project. More importantly, HPX has good record on maintain similar APIs for
> local and distributed cases; with such split, it might be difficult to spot
> bugs, if any.
>
>
>
> Best,
>
> Weile
>
>
>
> *From: *hpx-users-boun...@stellar-group.org <
> hpx-users-boun...@stellar-group.org> on behalf of Bita Hasheminezhad <
> bhas...@lsu.edu>
> *Date: *Wednesday, June 16, 2021 at 9:21 AM
> *To: *hpx-us...@stellar-group.org <hpx-us...@stellar-group.org>
> *Cc: *hpx-devel@stellar-group.org <hpx-devel@stellar-group.org>
> *Subject: *Re: [hpx-users] [VOTE] Proposal to split HPX into at least two
> smaller projects and repositories
>
> --1, My justification for not addressing the issue:
>
> I think developing projects on top of HPX would become extremely
> difficult. The goal for that software is probably to benefit all aspects of
> what HPX provides.
>
> HPX's idea of providing a stable semantic-C++ local and distributed
> parallel functionalities and having a successful history of achieving that
> are its essential features and what differentiates HPX from other
> not-so-successful projects.
>
>
>
> Regards,
>
> Bita
>
>
>
>
>
> Get Outlook for iOS
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=04%7C01%7Cwnanmi1%40lsu.edu%7Ca2a00a2e9a024dc7c51308d930d366dd%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637594506829418160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=suDexUd6sMfSqPLA9mG9Y%2FIzDRA6X8bbGARIVgMSobc%3D&reserved=0>
> ------------------------------
>
> *From:* hpx-users-boun...@stellar-group.org <
> hpx-users-boun...@stellar-group.org> on behalf of Parsa Amini <
> m...@parsaamini.net>
> *Sent:* Wednesday, June 16, 2021 8:41:22 AM
> *To:* hpx-us...@stellar-group.org <hpx-us...@stellar-group.org>
> *Cc:* hpx-devel@stellar-group.org <hpx-devel@stellar-group.org>
> *Subject:* Re: [hpx-users] [VOTE] Proposal to split HPX into at least two
> smaller projects and repositories
>
>
>
> - -1: ?no,? ?disagree?.
>
> > justification for not addressing the issue
>
> Separating the fundamental distributed and local-only functionalities of
> HPX compromises the project's integrity over time, if not rapidly, for the
> obvious reason that there will not be enough motivation to keep both in
> working co simultaneously. This will exacerbate if they are maintained in
> separate repositories but is still a problem even if they are maintained in
> the same repository (e.g., HPX support for Vc, HPX examples repository,
> MiniGhost, HPXCL).
>
> That this interest exists is understandable because our excellent
> collaborators at the CSCS have had to invest significant time and resources
> to maintain the distributed functionalities of HPX, which, at least in the
> short term, has not been sufficiently rewarding. On the other hand, the
> problem will be the opposite if the distributed functionalities become the
> focus, which will not be ideal either.
>
>
>
> Sincerely,
>
> Parsa Amini
>
>
>
> On Mon, Jun 7, 2021 at 2:53 PM Simberg Mikael <mikael.simb...@cscs.ch>
> wrote:
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhpx.stellar-group.org%2Fgovernance%2F&data=04%7C01%7Cwnanmi1%40lsu.edu%7Ca2a00a2e9a024dc7c51308d930d366dd%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637594506829428151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HuZxqzfPL5Ty4ddSzM4dhQ85kGvzuap3QqFLJunvRdY%3D&reserved=0>
> ):
>
> 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
> hpx-us...@stellar-group.org
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
> _______________________________________________
> hpx-users mailing list
> hpx-us...@stellar-group.org
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20210616/5f617b8d/attachment-0001.html
 

------------------------------

Message: 2
Date: Thu, 17 Jun 2021 01:28:24 +0200
From: Gregor Daiss <gregor.da...@gmail.com>
Subject: Re: [hpx-devel] [hpx-users] [VOTE] Proposal to split HPX into
        at least two smaller projects and repositories
To: hpx-us...@stellar-group.org
Cc: hpx-devel@stellar-group.org
Message-ID: <20210616232824.yr7pmgegcl6ryhq5@gnotebook>
Content-Type: text/plain; charset=utf-8; format=flowed

I vote +1 in favor of the split.

I was a bit torn between the two options, but overall I came to the conclusion 
that I prefer several smaller sub-projects over a large monolithic one.

In addition to the points Mikael already made, I like the sheer possibility of 
being able to downgrade parts of HPX independently of the rest. For example, 
right now I would actually like to have the CUDA executors introduced in HPX 
1.5.0 together with the distributed part of HPX 1.4.1 for some tests (sure, 
this might still fail for a whole host of reasons/incompatibilities depending 
on the actual versions but it would be nice to have the possibility in the 
first place - the versions mentioned here are just meant as an example).

This requires extensive testing of both repositories to work, of course. The 
latest releases should be guaranteed (best as possible) to work together. 
Ideally the CI of both repositories should trigger jobs which use them together 
(so that people who use master on both get fewer nasty surprises). All of this 
can be build on top of the already existing Jenkins CI at both LSU and CSCS.

As long as we keep the already existing communication infracstructure (IRC, 
biweekly meetings, mailings lists, Github group ...) I am also rather 
optimistic that the community will not drift apart as a result of this. On the 
contrary, I could see having an HPX core sub-project attract additional users.


Best regards,
Gregor

On Mon, Jun 07, 2021 at 07:53:06PM +0000, Simberg  Mikael wrote:
>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-users mailing list
>hpx-us...@stellar-group.org
>https://mail.cct.lsu.edu/mailman/listinfo/hpx-users



------------------------------

_______________________________________________
hpx-devel mailing list
hpx-devel@stellar-group.org
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel


End of hpx-devel Digest, Vol 72, Issue 11
*****************************************

Reply via email to