Boost logo

Boost-MPI :

Subject: Re: [Boost-mpi] Develop VS master
From: Richard (richard_at_[hidden])
Date: 2017-07-14 19:40:42

Hi Alain,

please don't get me wrong.
I would certainly appreciate merging the develop branch to the master to
get improvements and new features in boost.mpi.
And if develop is well tested already, I do not see any reason not to
merge it.
But I'm not in charge...

I just think the merge deserves to be independent of merely fixing the
master branch. The changes in develop are worth way more than just
fixing a regression.

I also do understand that you would like to avoid cherry-picking from
develop to master, but we are taking about a regression fix, not new
In fact I was just about to submit my own merge request of the patch I
wrote for this bug, when I found a similar fix in the develop branch.


On 07/14/2017 08:50 PM, Alain Miniussi wrote:
> 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 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
>>> 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
>>>, 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
>>>, 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:
>>>> 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:
>>>>> 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?
>>>>> (
>>>>> I would be really grateful if boost 1.65.0 had a working boost mpi
>>>>> again.
>>>>> Best,
>>>>> Richard
>>>>> _______________________________________________
>>>>> Boost-mpi mailing list
>>>>> Boost-mpi_at_[hidden]
>>>> _______________________________________________
>>>> Boost-mpi mailing list
>>>> Boost-mpi_at_[hidden]
>>> _______________________________________________
>>> Boost-mpi mailing list
>>> Boost-mpi_at_[hidden]
>> _______________________________________________
>> Boost-mpi mailing list
>> Boost-mpi_at_[hidden]

Boost-Commit list run by troyer at