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: [VOTE] Proposal to split HPX into at least two smaller
projects and repositories (Agust?n K-ballo Berg?)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 Jun 2021 18:08:59 -0300
From: Agust?n K-ballo Berg? <kaball...@hotmail.com>
Subject: Re: [hpx-devel] [VOTE] Proposal to split HPX into at least
two smaller projects and repositories
To: hpx-devel@stellar-group.org, Simberg Mikael
<mikael.simb...@cscs.ch>, "hpx-us...@stellar-group.org"
<hpx-us...@stellar-group.org>
Message-ID:
<sc1pr80mb41270df944e12d6fdb7e9a49a7...@sc1pr80mb4127.lamprd80.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
My vote is -1. I am in favor of splitting HPX into local-only and
distributed libraries, but I am strongly opposed to splitting the
project across multiple repositories.
With multiple repositories comes the need to synchronize them. The outer
project would have to constantly be polling the core project for
changes, bumping, testing, and then finally upgrading. Within a single
repository this happens automatically, with multiple repositories this
adds to boilerplate and noise in the form of constant bumps. The best
tool git offers (to my knowledge) to keep track of the relation between
repositories is submodules. They do allow to track the relation between
repositories on a per-branch basis, which is imperative, but as mere
hashes they tend to conflict all the time for merges and rebases. The
split would necessitate a lot of work and effort to keep the two parts
behaving as a cohesive thing, with the only exclusive advantage of
reducing network traffic a bit when cloning.
Splitting repositories could make more sense if the projects were
eventually going to be developed in a less entangled way. For example,
the distributed library could always track the last released version of
the core library, never top-of-master. But that would not work for a
research project, it would effectively turn distributed into a second
class citizen.
Alternative action: split libraries in a monorepo.
Regards,
--
Agust?n K-ballo Berg?
On 2021-06-07 4:53 PM, 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/
> <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
hpx-devel@stellar-group.org
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 72, Issue 3
****************************************
