Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)

Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-16 06:54:46

On Thu, Dec 16, 2010 at 7:19 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
>
> BoostPro Computing * http://boostpro.com
> [Sent from coveted but awkward mobile device]

I'm assuming this is an iPhone. ;)

> --
>
> On Dec 16, 2010, at 6:04 AM, Bruce Adams <tortoise_74_at_[hidden]> wrote:
>
[snip]
>
> +1 to all that. We try to respect peoples' sense of ownership but ultimately the only ones you need to get permission from are the moderators, and that's only if you want the code in Boost proper, because that's what we do here.

Interesting. So if I wanted to get SVN access and start working on
things in a private branch on the Boost SVN repository (for example,
to address a specific set of issues against a library Boost.X) and
then ask for a code review of the patch I'm potentially going to merge
to trunk at some point later, there's a process to do that?

>
> For the record, the big effort to track down Bill Kempf about boost.threads was to get his permission to *change the license* on his code. That's a whole other bag of cats

Ah, alright. Thanks for the clarification on that.

So given that a library is under the BSL, and in the Boost repository,
what is the process (now) to allow people to work directly on the
main-line of a library and start fixing issues? Is submitting tickets
to Trac with patches the only way to go about it? How about enabling
private branches, and having maintainers merge changes from specific
private branches as soon as a code review on the changes on the
private branch has been done?

I really am eager to know what the definitive answer to this is so
that us who really want to contribute to Boost have a clear
understanding of what it means to: 1) be a maintainer 2) get access to
the repository for commit access and 3) what the expectation is on
contributions and contributors alike. I guess this is the point where
there has to be a consensus on what the community really wants for the
Boost contribution process to be like.

Thanks for taking the time to clear things up. Hopefully something
comes out of this thread in the form of "community policy" that
members of the community can agree upon.

-- 
Dean Michael Berris
deanberris.com