On Fri, May 10, 2013 at 9:52 AM, Dave Abrahams
I personally find the subject line of this posting needlessly alarming.
From my viewpoint, it seems at least somewhat alarming that we are going into a review soon with the critical "develop" and "master" branches still not having the right names, and the https://github.com/boostorg/boost super-project for modular boost not usable for evaluation (or at least "git submodule update --init" apparently no longer working).
on Thu May 09 2013, Beman Dawes
wrote: If the steering committee's Git Modularization Review vote
What vote? We asked for a review period; maybe I shouldn't have used that word.
The reviews usually end with a Yes, No, or perhaps Conditionally Yes vote from the review submitter.
The intention was to give people a chance to make corrections to the way things were being modularized so we could move on to the next step. https://github.com/ryppl/Boost2Git/wiki#vetting-period
were held today, I've vote no since I think that we aren't yet ready. Since my concerns are apparently easy to fix technically, I'm mentioning them here to give Dave and Daniel a chance to address them before the actual Git Modularization Review starts.
Concerns:
1) The mapping of svn branch names to modular git branch names needs to be revised: Svn "trunk" needs to become modular git "develop", not "master". Modular git needs to have a branch "master" that represents the latest stable release. Whether the content is identical to the last boost release or to branches/release at point of conversion needs to be decided, as does what the history, if any, of this branch looks like.
Decided by whom? If it's up to us, we'll do whatever is expedient to avoid the threat of a "no vote"
Let's break that down into two questions. First, "Whether the content [of Master] is identical to the last boost release or to branches/release at point of conversion" Suggestion: We freeze the entire svn repo when the 1.54 release candidate is build. That becomes the point in time of conversion to git. IOW, the last boost release == branches/release at point of conversion to git, so the question becomes moot. Can we reach a consensus on that, and if necessary get it ratified by the Steering Committee? Second, "What does the history, if any, of master look like?" I've heard three possibilities: 1) History based on the difference between release tags. 2) History of the current svn branches/release. 3) No history at all. (The tags are still available, so if anyone cares they diff the differences.) (1) or (2) are my preference, but (3) is also acceptable. I wouldn't want the choice to delay the schedule. My feeling is that you should make the call, after consulting with Daniel. You have a broad overview of the needs of the community and also understand the history mechanism much better than most of us.
2) The procedures described in https://svn.boost.org/trac/boost/wiki/TryModBoost need to be updated, the dependency on CMake needs to be removed, and the procedures need to work.
Where did these prerequisites come from?
By looking at the prerequisites for each of the command line steps in https://svn.boost.org/trac/boost/wiki/TryModBoost.
You wrote the web page; are you going to update it? https://svn.boost.org/trac/boost/wiki/TryModBoost?action=history
I'm being blocked by the "git submodule update --init" step not working, and not knowing what the replacement is for the "cmake -P forward_headers.cmake" step.
These are blocking issues because they prevent development and testing of modular boost testing procedures, developers procedures, release procedures, installation procedures, and documentation. Until they are resolved, the entire modular boost conversion rests on the shoulders of Dave and Daniel. Once they are resolved, others can pitch in and help since from that point forward we will be in a pure git environment and detailed knowledge of the conversion process from svn is not required.
I understand that these are blocking issues for the switchover. We're not asking people to approve an immediate switchover; we're just asking for people to make fixes and requests regarding how things are sorted into modules.
It isn't just that they are blocking issues for the switchover. They are also blocking issues for making progress on documentation and developing test and release procedures. That said, the separation of libraries into separate modules with full history is looking very much improved! --Beman