On 12/16/10, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Dec 16, 2010 at 7:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device]
I'm assuming this is an iPhone. ;)
'Fraid it was, yes.
On Dec 16, 2010, at 6:04 AM, Bruce Adams <tortoise_74@yahoo.co.uk> 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?
No, but it doesn't mean we can't do it. It just hadn't come up, yet, so we never set up a process.
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?
That's all we've got set up ATM, but that doesn't mean anything about what's possible.
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?
Sounds okay to me; I don't know what the technical/administrative hurdles might be to doing that through SVNManager, but it could get 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.
How about you make a proposal?
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.
That would be awesome. -- Dave Abrahams BoostPro Computing http://www.boostpro.com