Hi Richard,
On 14/07/2017 18:54, Richard via Boost-mpi wrote:
Hi Alain,
I'm not a boost developer so I'm not sure what boost's policies are.
In my opinion merging develop to master and fixing the regression are
two separate issues, which should get addressed separately.
I think taking a broken master as an "excuse" to merge a development
branch is not a good idea. You should merge a development branch because
it has nice new features and other desirable improvements, not because
it will also fix the tiny problem which put the master branch into an
unusable state.
Well, as pointed out, develop *has* interesting features.
Whatever is in develop has been put there through pull requests
from either other branches of the repository (for people with access)
or repository forks, and hopefully discussed and validated.
Develop is not an experimental branch.
It's just not supposed to be tested as deeply as master before being
accepted. But it's been a few months now since the testing of develop
is actually in better shape than the one of master (probably just for
that bug though).
But I get your point and merging that specific change is certainly an
options.
Note that it's been a long time since changes made to develop are
not transfered to master and that has consequences too. It basically
means that there are no reason to contribute to Boost.MPI.
Regards
Alain
The merging process may also take a while due to code reviews of large
changes.
On the other hand, a bug that breaks the master should get addressed
with a proper fix as soon as possible (unless the another library
changed in such a substantial way, that large parts of the code need to
be adapted - which does not seem to be the case here).
Ideally, fixing such a bug should be possible within a very short time,
since only a small fix has to be reviewed.
If can be of any help of any help on this matter, please let me know.
Best,
Richard
On 07/14/2017 04:35 PM, Alain Miniussi via Boost-mpi wrote:
Hi,
As you probably know, 1.64 is not building. That reflect the fact that
serialization/master broke backward compatibility (in the detail area, a
part Boost.MPI should not rely on in the first place, but that's another
story).
MPI/develop is ok in that respect, as a mater of fact develop seems to
pass its tests on all the platforms I have access to (linux with g++
icpc and intel MPIs).
I proposed https://github.com/boostorg/mpi/pull/46 in February which is
a merge from develop on master, hoping it would be in for 1.64. It is my
opinion that develop should be regularly merge on master after proper
testing, but that opinion is not shared by all the people with merge
authorization.
You can read the discussion in https://github.com/boostorg/mpi/pull/46
for details. Basically the argument against merging is that it would
break some antique platform, but I was unable to get the informations:
which platform, what breaks, compile error messages etc...
It's been suggested to only move changes to master through cherry
picking, which I'm against since I think it's a maintenance nghtmare
that waste contributor's time and efforts.
So right now, what I would like to see is a merge of develop to master
or a clear description of what to be fixed in develop preventing that.
The pro and cons I can think of:
PROS:
- Master is broken anyway
- All the test I was able to perform passed ok
- develop has some interesting features (cartesian communicator,
variable size versions of global operations to name some)
CONS:
- If I do the merge, I'll be both the guy who submitted the pull request
and the one validating the pool request, which is not good practice IMO.
- some test are failing in
http://www.boost.org/development/tests/develop/developer/mpi.html, but
the only messages I could get indicates a configuration error (some flag
is used that is not supported by the compiler).
- linked to the previous problem: I only have access to some platform
(linus, intel and gnu compilers, Intel and some OpenMPI). As you know,
the cross product of plateform/MPI/compiler version is...big.
So, I would like to have your input on that issue (maybe through
https://github.com/boostorg/mpi/pull/46, maybe not ?) and, very
important, if you could test develop on your platform and share the
results.
Do you think we should try to get develop on master for the 1.65 ?
Regards,
Alain
On 14/07/2017 10:17, Alain Miniussi via Boost-mpi wrote:
Please see the discussion in:
https://github.com/boostorg/mpi/pull/46
I'm going to send an email to the list to see what we can do.
Regards
Alain
On 13/07/2017 20:20, Richard via Boost-mpi wrote:
Dear Boost MPI developers and maintainers,
since none of the developers or maintainers commented on the ticket
within the last half a year, I would like to make sure you are aware of
this bug:
https://svn.boost.org/trac10/ticket/12723
Could someone please see to it that this does not make it to the next
release?
It's really not difficult to fix and I think it's pretty bad this made
it to boost 1.64.
But now it's even in 1.65.0 beta 1!!
Why doesn't the simple fix in the develop branch of boost mpi get
merged?
(https://github.com/boostorg/mpi/commit/f5bdcc1ebfe954bb64835f2a0efd94471da42207)
I would be really grateful if boost 1.65.0 had a working boost mpi
again.
Best,
Richard
_______________________________________________
Boost-mpi mailing list
[email protected]
https://lists.boost.org/mailman/listinfo.cgi/boost-mpi
_______________________________________________
Boost-mpi mailing list
[email protected]
https://lists.boost.org/mailman/listinfo.cgi/boost-mpi
_______________________________________________
Boost-mpi mailing list
[email protected]
https://lists.boost.org/mailman/listinfo.cgi/boost-mpi
_______________________________________________
Boost-mpi mailing list
[email protected]
https://lists.boost.org/mailman/listinfo.cgi/boost-mpi
_______________________________________________
Boost-mpi mailing list
[email protected]
https://lists.boost.org/mailman/listinfo.cgi/boost-mpi
