[test] Applying outstanding pull requests to develop and schedule merge of develop to master
Some time ago (more than 2 years) I submitted a set of four complimentary patches for Boost.Test of which one was partially applied. The tickets are: * Test Units (Cases and Suites) in Boost.Test do not capture __FILE__ and __LINE__ at declaration point making it impossible to provide source file linking using external test management tools https://svn.boost.org/trac/boost/ticket/7410 (modified patch applied) * Boost.Test, since boost 1.48 is using the deprecated Boost.Timer class - it should be updated to use the new class https://svn.boost.org/trac/boost/ticket/7397 https://github.com/boostorg/test/pull/15 * Detailed test status is not available in the Boost.Test log (status, assertions, passed) and so live test case status cannot be tracked https://svn.boost.org/trac/boost/ticket/7417 https://github.com/boostorg/test/pull/16 * Support multiple calls to framework::init() allowing wrappers to support running tests using test tools in full systems https://svn.boost.org/trac/boost/ticket/7419 https://github.com/boostorg/test/pull/17 I've updated and resubmitted patches on more than one occasion and also variously created patches against (the now) develop and master so I can actually apply them for myself for each new boost version. Now, the reason for my post is two-fold. First - I'd like to see these patches applied. They cause no user impacts and simply (a) fix broken functionality and (b) *significantly* improve the usefulness of Boost.Test. I am more than happy to help with maintaining Boost.Test since we rely on it heavily and I believe, on the whole it is a good library. Second - it is about time we formulated a schedule for merging develop into master for Boost.Test. Otherwise all the patches in the world are simply pointless. The patches I've submitted, like others will never see the light of day even if they are applied because develop is very different than master and it looks like a merge may never happen. It should be noted that for my patches I have a completely different set that I apply to an actual Boost release because of the large differences between the two branches. To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master. The longer it is left the worse the impact will be. A lot of good work has been done on develop - the longer it stays there the more people will move away from Boost.Test in their own code and it will only have relevance to Boost libraries themselves. Jamie
On 12/11/2014 04:28 PM, Jamie Allsop wrote:
To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master. The longer it is left the worse the impact will be. A lot of good work has been done on develop - the longer it stays there the more people will move away from Boost.Test in their own code and it will only have relevance to Boost libraries themselves.
Jamie
I really think that boost test needs to be it's own product (and development cycle) and that Boost references a released binary of it.
Brian Schrom
On 12/11/2014 04:28 PM, Jamie Allsop wrote:
To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master. The longer it is left the worse the impact will be. A lot of good work has been done on develop - the longer it stays there the more people will move away from Boost.Test in their own code and it will only have relevance to Boost libraries themselves.
Jamie
I really think that boost test needs to be it's own product (and development cycle) and that Boost references a released binary of it.
Isn't this what Modular Boost is all about? Boost.Test master is latest release everybody depends on. Boost.Test devel is where new features are developed. Gennadiy
On 12/26/2014 10:17 AM, Gennadiy Rozental wrote:
Brian Schrom
writes: I really think that boost test needs to be it's own product (and development cycle) and that Boost references a released binary of it.
Isn't this what Modular Boost is all about? Boost.Test master is latest release everybody depends on. Boost.Test devel is where new features are developed.
Gennadiy
Nearly, I just think it would be better to decouple the release process of Boost.Test from the release of Boost. That way, when you feel that Boost.Test (develop) is stable, you can make a new Boost.Test (master) independent of the Boost release cycle. The pinning in Boost master shouldn't be automatic, and it should happen when the trunk is open for merges and be stable before the Boost release cycle starts. (admittedly I'm not sure, maybe it is already this way)
Brian Schrom
The pinning in Boost master shouldn't be automatic, and it should happen when the trunk is open for merges and be stable before the Boost release cycle starts. (admittedly I'm not sure, maybe it is already this way)
Yes. I believe the process setup this way already and from where I stand if should be fine for our purposes.
Jamie Allsop
To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master.
Yes. I fully agree with this statement. I hope to get back to this list with more concrete schedule soon. And if you are interested to push this even sooner - please feel free to help. Gennadiy
On 26/12/14 10:19, Gennadiy Rozental wrote:
Jamie Allsop
writes: To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master.
Yes. I fully agree with this statement. I hope to get back to this list with more concrete schedule soon. And if you are interested to push this even sooner - please feel free to help.
That's great news. I know a vast amount of work has gone into develop and we'll all benefit when it finally gets merged into master. Yes, I'm happy to support this effort as best I can. Feel free to contact me off-list. Thanks for working hard to move this forward. Boost.Test has always been a critical library and as a result somewhat of a thankless task to maintain given the constant risk of breakage across Boost as a whole. Thanks for persevering. Jamie
Gennadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Brian Schrom -
Gennadiy Rozental -
Jamie Allsop