[regression] OK to merge? Should tools/regression be a submodule?
* The directory tools/regression/src/report was missing from svn branches/release, so it is also missing from modular boost master. Although I haven't checked, that probably means the are other unmerged changes in develop. OK to merge develop to master (after suitable testing?) * Should tools/regression be a submodule? Does anyone remember why it remains a part of the super-project? If we are going to convert tools/regression to a submodule, should we do it now or wait until the dust settles? --Beman
Beman Dawes wrote:
* The directory tools/regression/src/report was missing from svn branches/release, so it is also missing from modular boost master. Although I haven't checked, that probably means the are other unmerged changes in develop.
OK to merge develop to master (after suitable testing?)
Judging by the list of changes that C:\Projects\boost-git\boost>git diff --name-status master..develop shows, I'd think twice before doing such a merge. :-) M .gitmodules M Jamroot M boostcpp.jam A boostcpp.py M bootstrap.bat M bootstrap.sh M doc/Jamfile.v2 M doc/pdf/Jamfile.v2 M doc/src/boost.xml M doc/src/minimal.css A doc/test/test.mml A doc/test/test.png M doc/test/test.qbk A doc/test/test.svg M libs/accumulators M libs/algorithm M libs/any M libs/array M libs/asio M libs/assign M libs/atomic M libs/bimap M libs/bind M libs/chrono M libs/circular_buffer M libs/compatibility M libs/concept_check M libs/config M libs/container M libs/context M libs/conversion M libs/coroutine M libs/crc M libs/date_time M libs/detail M libs/disjoint_sets M libs/dynamic_bitset M libs/exception M libs/filesystem M libs/flyweight M libs/foreach M libs/format M libs/function M libs/function_types M libs/functional M libs/fusion M libs/geometry M libs/gil M libs/graph M libs/graph_parallel M libs/heap M libs/icl M libs/integer M libs/interprocess M libs/intrusive M libs/io M libs/iostreams M libs/iterator M libs/lambda M libs/libraries.htm M libs/local_function M libs/locale M libs/lockfree M libs/log M libs/logic M libs/math M libs/move M libs/mpi M libs/mpl M libs/msm M libs/multi_array M libs/multiprecision M libs/numeric/conversion M libs/numeric/interval M libs/numeric/odeint M libs/numeric/ublas M libs/optional M libs/parameter M libs/phoenix M libs/polygon M libs/pool M libs/predef M libs/preprocessor M libs/program_options M libs/property_map M libs/property_tree M libs/proto M libs/ptr_container M libs/python M libs/random M libs/range M libs/ratio M libs/rational M libs/regex M libs/scope_exit M libs/serialization M libs/signals M libs/signals2 M libs/smart_ptr M libs/spirit M libs/statechart M libs/static_assert A libs/sync M libs/system M libs/test M libs/thread M libs/timer M libs/tokenizer M libs/tr1 M libs/tti M libs/tuple M libs/type_erasure M libs/type_traits M libs/typeof M libs/units M libs/unordered M libs/utility M libs/uuid M libs/variant M libs/wave M libs/xpressive M more/getting_started/detail/conclusion.rst M more/getting_started/unix-variants.html M more/getting_started/windows.html M status/Jamfile.v2 A status/boost-no-inspect M status/explicit-failures-markup.xml M tools/auto_index M tools/bcp M tools/boostbook M tools/build M tools/inspect M tools/quickbook A tools/regression/src/git.py M tools/regression/src/library_status.cpp M tools/regression/src/process_jam_log.cpp M tools/regression/src/regression.py A tools/regression/src/report/add_expected_results.cpp A tools/regression/src/report/add_expected_results.hpp A tools/regression/src/report/boost_report.cpp A tools/regression/src/report/common.cpp A tools/regression/src/report/common.hpp A tools/regression/src/report/html.cpp A tools/regression/src/report/html.hpp A tools/regression/src/report/html_writer.hpp A tools/regression/src/report/issues_page.cpp A tools/regression/src/report/issues_page.hpp A tools/regression/src/report/links_page.cpp A tools/regression/src/report/links_page.hpp A tools/regression/src/report/produce_expected_results.cpp A tools/regression/src/report/produce_expected_results.hpp A tools/regression/src/report/result_page.cpp A tools/regression/src/report/result_page.hpp A tools/regression/src/report/runners.cpp A tools/regression/src/report/runners.hpp A tools/regression/src/report/summary_page.cpp A tools/regression/src/report/summary_page.hpp A tools/regression/src/report/xml.cpp A tools/regression/src/report/xml.hpp A tools/regression/src/report/zip.hpp M tools/regression/src/run.py M tools/regression/src/run_tests.sh A tools/regression/test/report/Jamfile.jam A tools/regression/test/report/comment.html A tools/regression/test/report/expected.zip A tools/regression/test/report/expected_results.xml A tools/regression/test/report/explicit-failures-markup.xml A tools/regression/test/report/runner.xml M tools/regression/xsl_reports/boost_wide_report.py M tools/regression/xsl_reports/build_results.sh M tools/release/README D tools/release/build_docs.sh D tools/release/build_release.sh D tools/release/build_release_packages.sh A tools/release/inspect.py D tools/release/inspect.sh D tools/release/inspect_trunk.bat D tools/release/load_posix.sh D tools/release/load_windows.sh D tools/release/make_packages.sh A tools/release/merge2release.bash D tools/release/release_reports.sh A tools/release/snapshot.py D tools/release/snapshot.sh D tools/release/snapshot_inspect.sh M tools/release/snapshot_inspection.bat D tools/release/snapshot_posix.sh D tools/release/snapshot_windows.sh A tools/server/subversion/hooks/authorize.grep.disabled A tools/server/subversion/hooks/case-insensitive.py A tools/server/subversion/hooks/check-mime-type.pl A tools/server/subversion/hooks/post-commit A tools/server/subversion/hooks/post-commit.tmpl A tools/server/subversion/hooks/post-lock.tmpl A tools/server/subversion/hooks/post-revprop-change.tmpl A tools/server/subversion/hooks/post-unlock.tmpl A tools/server/subversion/hooks/pre-commit A tools/server/subversion/hooks/pre-commit.bak A tools/server/subversion/hooks/pre-commit.release A tools/server/subversion/hooks/pre-commit.tmpl A tools/server/subversion/hooks/pre-lock.tmpl A tools/server/subversion/hooks/pre-revprop-change A tools/server/subversion/hooks/pre-revprop-change.tmpl A tools/server/subversion/hooks/pre-unlock.tmpl A tools/server/subversion/hooks/start-commit.tmpl A tools/server/subversion/hooks/test-post-commit A tools/server/subversion/hooks/trac-post-commit-hook A tools/server/subversion/hooks/trac-post-commit-hook.old A tools/server/subversion/hooks/xml-check.sh
On Thu, Jan 2, 2014 at 10:10 AM, Peter Dimov <lists@pdimov.com> wrote:
Beman Dawes wrote:
* The directory tools/regression/src/report was missing from svn branches/release, so it is also missing from modular boost master. Although I haven't checked, that probably means the are other unmerged changes in develop.
OK to merge develop to master (after suitable testing?)
Judging by the list of changes that
C:\Projects\boost-git\boost>git diff --name-status master..develop
shows, I'd think twice before doing such a merge. :-)
M .gitmodules M Jamroot M boostcpp.jam A boostcpp.py M bootstrap.bat M bootstrap.sh M doc/Jamfile.v2 M doc/pdf/Jamfile.v2 M doc/src/boost.xml M doc/src/minimal.css A doc/test/test.mml A doc/test/test.png M doc/test/test.qbk A doc/test/test.svg M libs/accumulators <long list>
The merge would have to be cherry picked:-( That would be an example of why making tools/regression a submodule is worthwhile. If we do that first, and then the merge afterwards, life gets simpler. --Beman
Beman Dawes wrote:
That would be an example of why making tools/regression a submodule is worthwhile. If we do that first, and then the merge afterwards, life gets simpler.
One might even say that this is an argument for making everything a submodule, leaving almost nothing in the superproject.
On Thu, Jan 2, 2014 at 10:31 AM, Peter Dimov <lists@pdimov.com> wrote:
Beman Dawes wrote:
That would be an example of why making tools/regression a submodule is worthwhile. If we do that first, and then the merge afterwards, life gets simpler.
One might even say that this is an argument for making everything a submodule, leaving almost nothing in the superproject.
Good point. IIRC, several people argued for that right from the start. I was a bit resistant until we developed more expertise working with submodules, but now that I've actually been working with submodules I'm leaning much more toward the "leaving almost nothing in the superproject" viewpoint.
On 2 January 2014 14:50, Beman Dawes <bdawes@acm.org> wrote:
* Should tools/regression be a submodule?
Should it be part of the boost tree? Since it downloads boost into a subdirectory, it looks like something that exists outside of the tree. Either way, IMO we should be moving as much as possible out of the super project.
On Thu, Jan 2, 2014 at 10:29 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 2 January 2014 14:50, Beman Dawes <bdawes@acm.org> wrote:
* Should tools/regression be a submodule?
Should it be part of the boost tree? Since it downloads boost into a subdirectory, it looks like something that exists outside of the tree.
Good point. The same might be true of several other tools, like tools/inspect. --Beman
On 1/2/2014 11:24 AM, Beman Dawes wrote:
On Thu, Jan 2, 2014 at 10:29 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 2 January 2014 14:50, Beman Dawes <bdawes@acm.org> wrote:
* Should tools/regression be a submodule?
Should it be part of the boost tree? Since it downloads boost into a subdirectory, it looks like something that exists outside of the tree.
Good point. The same might be true of several other tools, like tools/inspect.
I do not see why a tool which manipulates the Boost tree totally outside of git should not be part of the Boost tree. One thing ( manipulating the Boost tree in some way ) does not preclude the other ( being part of the tree ) in my mind. Clearly the Boost tree can be changed locally outside of what git does in regard to version control.
On 2 January 2014 18:54, Edward Diener <eldiener@tropicsoft.com> wrote:
On 1/2/2014 11:24 AM, Beman Dawes wrote:
On Thu, Jan 2, 2014 at 10:29 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 2 January 2014 14:50, Beman Dawes <bdawes@acm.org> wrote:
* Should tools/regression be a submodule?
Should it be part of the boost tree? Since it downloads boost into a subdirectory, it looks like something that exists outside of the tree.
Good point. The same might be true of several other tools, like tools/inspect.
I do not see why a tool which manipulates the Boost tree totally outside of git should not be part of the Boost tree. One thing ( manipulating the Boost tree in some way ) does not preclude the other ( being part of the tree ) in my mind. Clearly the Boost tree can be changed locally outside of what git does in regard to version control.
Nothing is precluded, but separating things makes life easier. Is there a reason why it needs to be part of the tree?
On 1/2/2014 2:43 PM, Daniel James wrote:
On 2 January 2014 18:54, Edward Diener <eldiener@tropicsoft.com> wrote:
On 1/2/2014 11:24 AM, Beman Dawes wrote:
On Thu, Jan 2, 2014 at 10:29 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 2 January 2014 14:50, Beman Dawes <bdawes@acm.org> wrote:
* Should tools/regression be a submodule?
Should it be part of the boost tree? Since it downloads boost into a subdirectory, it looks like something that exists outside of the tree.
Good point. The same might be true of several other tools, like tools/inspect.
I do not see why a tool which manipulates the Boost tree totally outside of git should not be part of the Boost tree. One thing ( manipulating the Boost tree in some way ) does not preclude the other ( being part of the tree ) in my mind. Clearly the Boost tree can be changed locally outside of what git does in regard to version control.
Nothing is precluded, but separating things makes life easier. Is there a reason why it needs to be part of the tree?
If it needs to know where the Boost tree is at, then keeping it in the Boost tree seems right, since it can use relative paths to find what it needs. OTOH if there is no dependency on anything else in the Boost tree, by all means make it separate.
On Thu, Jan 2, 2014 at 7:05 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 1/2/2014 2:43 PM, Daniel James wrote:
On 2 January 2014 18:54, Edward Diener <eldiener@tropicsoft.com> wrote:
On 1/2/2014 11:24 AM, Beman Dawes wrote:
On Thu, Jan 2, 2014 at 10:29 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 2 January 2014 14:50, Beman Dawes <bdawes@acm.org> wrote:
* Should tools/regression be a submodule?
Should it be part of the boost tree? Since it downloads boost into a subdirectory, it looks like something that exists outside of the tree.
Good point. The same might be true of several other tools, like tools/inspect.
I do not see why a tool which manipulates the Boost tree totally outside of git should not be part of the Boost tree. One thing ( manipulating the Boost tree in some way ) does not preclude the other ( being part of the tree ) in my mind. Clearly the Boost tree can be changed locally outside of what git does in regard to version control.
Nothing is precluded, but separating things makes life easier. Is there a reason why it needs to be part of the tree?
If it needs to know where the Boost tree is at, then keeping it in the Boost tree seems right, since it can use relative paths to find what it needs. OTOH if there is no dependency on anything else in the Boost tree, by all means make it separate.
It really will make maintenance simpler if the files in tools/regression are their own project with their own public repository. That's important. So far, all our separate tool projects are treated as sub-projects by the boost super-project. But that's more from the habit of thinking of them as part of the boost repo than from any strong technical need. --Beman
On 01/02/2014 08:50 AM, Beman Dawes wrote:
* The directory tools/regression/src/report was missing from svn branches/release, so it is also missing from modular boost master. Although I haven't checked, that probably means the are other unmerged changes in develop.
OK to merge develop to master (after suitable testing?)
* Should tools/regression be a submodule? Does anyone remember why it remains a part of the super-project? If we are going to convert tools/regression to a submodule, should we do it now or wait until the dust settles?
I see that the discussion of super-project workflow has been re-opened, but have not had a chance to review the updated document in detail. As that discussion is underway, I think both proposals to change master are premature. I strongly object to destabilizing the super-project master branch, and I cannot see how cherry-picking from develop into it, and factoring submodules out of it, would not do exactly that. The stability requirements imposed on module master branches---that they always be in a releasable state---apply even more so to the super-project master branch. If anything, the merge should be from master to develop, then a wholesale merge from develop to master. (I do not mean that the master branch can be merged to only to create a release; I mean that the head of the master branch at all times should meet basic releasibility requirements including interoperability and successful regression tests on all supported platforms.) Peter
participants (5)
-
Beman Dawes -
Daniel James -
Edward Diener -
Peter A. Bigot -
Peter Dimov