Re: [boost] [Git] Documentation for Git and Modular Boost conversion

Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-12-16 10:01:21

On Sat, Dec 15, 2012 at 10:31 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> On Sat, Dec 15, 2012 at 8:39 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
...
>>
>> Now you can make administrative requests at
>> https://github.com/boost-lib/admin/issues
>>
>> Setting this up is a little clumsy, but what I did was to make a team
>> called "admin" and a repo called "admin" under the boost-lib
>> organization, and assigned the repo to the team.  The team (right now,
>> and totally subject to adjustment) is Daniel Pfeifer, Beman Dawes, Eric
>> Niebler, and me.  We're also on the special "owners" team for the
>> boost-lib org.  According to GitHub docs, the team will receive email
>> for every issue opened on that tracker.
>>
>
> OK. But I guess after thinking about this more I'm more wondering what the
> security, permissions, responsibilities, library release flow, etc. will
> work?

> Do developers get to own the boost sublib repos, and hence manage
> when and how their libraries make it into the releases?

Yes, subject to details. Also, a library can do a release whenever
convenient, and it become available to users at that point, even
though the next Boost release may be some time off. Users who care can
employ the GitHub watch mechanism to know what is happening to a
library. See https://help.github.com/articles/be-social

> Or only the Boost
> admins, and the developers have to ask the admins to update from clones?

I'm not sure what the exact mechanism will be - Git gives us several
choices and the release managers need to start to look at what way we
want to do it.

> Sorry if this is already documented somewhere, but I don't remember reading
> it when I first read Beman's new docs.

Some of it isn't documented because of time pressure, or because I'm
not aware of details worked out by others, or because the details
aren't worked out at all yet.

Part of my rationale for "release early, release often" wrt docs was
to flush out areas where we need to make decisions.

I'm overwhelmed at the moment, but perhaps in a week or ten days we
can get a new discussion started about how releases will work. In the
meantime, reading about how Git sub-modules work might be useful prep.

--Beman