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

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-13 01:00:04

on Sun May 12 2013, Beman Dawes <bdawes-AT-acm.org> wrote:

> 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, 

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

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-tp4646659p4646739.html
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