
On Sat, Dec 15, 2012 at 10:31 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Sat, Dec 15, 2012 at 8:39 PM, Dave Abrahams <dave@boostpro.com> 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