Re: [boost] Git Modularization Review no vote heads-up

on Sun May 12 2013, Beman Dawes wrote:

On Fri, May 10, 2013 at 9:52 AM, Dave Abrahams wrote:

...

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,

It's clear that you are somewhat alarmed, yes. The "review" that we're asking for is there in part so that the community can decide what "the right names" are. As Daniel pointed out quite nicely I think, there is no single obvious right answer. That said, if you think the right answer is obvious, we can make the necessary change at a moment's notice. Just tell us what you want. Anything we do is easily reversed.

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).

That's because when people asked for modularized history, what we were doing previously—just creating a snapshot of the submodules where they are, going forward—was no longer the correct answer. I could easily provide you with a 10-line bash script that checks the head of all the submodules out at their proper locations, but getting them to be correctly represented though the entire history of Boost is requiring a lot of coding (I think I'm very close, though).

...

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.

Yes, "review" was the wrong word; I see that now.

...

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?

I don't understand how this relates to what we're asking people to evaluate. We want to know if they're happy with where the files are going in the Git repos and what branches and/or tags they're being directed to. If people aren't happy, we want to make adjustments. A perfect example of the kind of information we need is in http://boost.2283326.n4.nabble.com/Git-Modularization-Ready-for-Review-tp464... where Vicente Botet wrote, | Could I move the following from repository thread to core? | | "boost/detail/atomic_redef_macros.hpp" : | "include/boost/detail/atomic_redef_macros.hpp"; | "boost/detail/atomic_undef_macros.hpp" : | "include/boost/detail/atomic_undef_macros.hpp"; I added these | files. They are used now by Boost.Thread, but it should be used by | SmartPtr (See https://svn.boost.org/trac/boost/ticket/6842 and | https://svn.boost.org/trac/boost/ticket/6843).

Second, "What does the history, if any, of master look like?"

Wait; don't we care about the history of any of the other branches? Daniel and I have spent months getting that right because the community insisted on it.

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,

2 is trivially accomplished. 1 would take more work.

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.

Well, I don't personally think history matters that much, and I think having a history that matches git-flow's usage matters even less, since after all we haven't actually been using git-flow, so it would be artificial. It would be nice to do a "perfect" job, but I'm not sure it's worth the effort.

...

...

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 things are both important for making the transition, but they're not important to the particular review we were asking for.

...

...

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.

Sure. I'm working hard on it.

That said, the separation of libraries into separate modules with full history is looking very much improved!

Well, I know it isn't glamorous and it doesn't satisfy the need to say "look it builds," but *that* is what we're asking people to evaluate now. -- Dave Abrahams