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

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-05-12 15:52:59

On Fri, May 10, 2013 at 9:52 AM, Dave Abrahams <dave_at_[hidden]> 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, 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 <bdawes-AT-acm.org> 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