Coordinating Parameter 'master' merging for dependent libraries

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Coordinating Parameter 'master' merging for dependent libraries

Boost - Dev mailing list
I intend to merge Parameter 'develop' to 'master' for the next release
of Boost. Cromwell Enage has done a great job of adding modern
improvements to the Parameter library via PRs, while maintaining full
backward compatibility with the Parameter public interface. I have
reviewed and approved those changes and, where I have been lax, Peter
Dimov has pointed out weaknesses in some of those changes, which
Cromwell has corrected. The changes which Cromwell has made have also
involved improvements in the Parameter private interface(s), which have
entailed some updates to the 'develop' branch of some Boost libraries
which unfortunately depended on some aspects of the Parameter private
interface. These updates have already been made in those other library's
'develop' branch. At this point any further possible changes for
Parameter for a while will very likely be in the Parameter
documentation, which requires no syncing with other libraries, so this
is an excellent time for merging.

Since the merging for other libraries dependent on Parameter must be
synced to the merging of Parameter from 'develop' to 'master' what is
the best way to go about this ? Obviously I have first to merge
Cromwell's changes from 'develop' to 'master', which is easily done. How
should I inform other libraries that they need to merge their Parameter
dependent 'develop' changes to 'master' ? Should I create PRs for doing
this ? We do not normally create PRs for the 'master' branch of any
Boost library. Should I create Issues for those other libraries and hope
the maintainers of the other libraries will take the appropriate action
? Or should I inform the maintainers of the other libraries in this
thread, and prompt them to review their changes here to get them to
merge them from 'develop' to 'master' ?

The other libraries involved are: Accumulators, Log, Convert, Lockfree,
Signals2, and Graph. Cromwell knows more about the specific 'develop'
changes in those libraries which need to be merged to 'master' than I
do, since he was instrumental in creating the PRs that would allow these
libraries to work with the updated Parameters' internals, so he may
chime in here, but I would like to get this done so that Parameter and
its dependent Boost libraries get properly updated for the next Boost
release. Of course I will also plan with Cromwell update notes for
Parameter to be part of the next release.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Coordinating Parameter 'master' merging for dependent libraries

Boost - Dev mailing list
On 2/2/19 1:16 AM, Edward Diener via Boost wrote:

>
> Since the merging for other libraries dependent on Parameter must be
> synced to the merging of Parameter from 'develop' to 'master' what is
> the best way to go about this ? Obviously I have first to merge
> Cromwell's changes from 'develop' to 'master', which is easily done. How
> should I inform other libraries that they need to merge their Parameter
> dependent 'develop' changes to 'master' ? Should I create PRs for doing
> this ? We do not normally create PRs for the 'master' branch of any
> Boost library. Should I create Issues for those other libraries and hope
> the maintainers of the other libraries will take the appropriate action
> ? Or should I inform the maintainers of the other libraries in this
> thread, and prompt them to review their changes here to get them to
> merge them from 'develop' to 'master' ?

I did create "Merge develop to master" kind of PRs for some libraries.
I'm not sure how convenient it is for other library maintainers, but
even if they prefer to merge themselves, the PR can simply serve as a
reminder, the same way a ticket does. There's no obligation to actually
merge that PR.

> The other libraries involved are: Accumulators, Log, Convert, Lockfree,
> Signals2, and Graph.

Boost.Log is already merged. Its develop and master are the same and are
compatible with both Boost.Parameter develop and master.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Coordinating Parameter 'master' merging for dependent libraries

Boost - Dev mailing list
On 2/2/19 1:16 AM, Edward Diener via Boost wrote:
> The other libraries involved are: Accumulators, Log, Convert, Lockfree,
> Signals2, and Graph.

The 'develop' branches of Boost.Accumulators, Boost.Convert,
Boost.Lockfree, and Boost.Signals2 rely solely on the public interface of
the 'develop' branch of Boost.Parameter.  Only Boost.Graph remains deviant
in that regard, but since that access is encapsulated by bgl_named_params,
at this point I'm more concerned with upgrading Boost.Graph algorithms via
Boost.Parameter's code generation macros, which provide modern alternatives
to bgl_named_params.  However, I'll need PR #73 reviewed for acceptance to
Boost.Parameter before I can start submitting PRs to Boost.Graph in that
direction.  Nevertheless, I'm willing to wait until after the merging to
master is complete or even until after 1.70 is released.

Cromwell D. Enage

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost