On Sun, Aug 27, 2017 at 7:12 AM, Daniel James via Boost wrote:

Pull requests are tested on boostorg.

1. Authors can do pull requests against develop and master in their own forks 2. If no one worked in topical branches directly in boostorg repos, there would be much more CI bandwidth available for third party pull requests made against boostorg repos

On Sun, Aug 27, 2017 at 10:09 AM, Daniel James via Boost wrote:

On 27 August 2017 at 16:20, Vinnie Falco via Boost wrote:

...

On Sun, Aug 27, 2017 at 7:12 AM, Daniel James via Boost wrote:

...

Pull requests are tested on boostorg.

1. Authors can do pull requests against develop and master in their own forks

Here's a pull request I created:

https://github.com/boostorg/beast/pull/709

I created it from a fork. Click on the little green tick:

https://travis-ci.org/boostorg/beast/builds/259865444?utm_source=github_status&utm_medium=notification

It was tested on boostorg.

We need a central place for people to create pull requests - they can't be expected to track down the correct account for individual repos.

...

2. If no one worked in topical branches directly in boostorg repos, there would be much more CI bandwidth available for third party pull requests made against boostorg repos

Most developers want to integrate their changes into develop regularly. That way their changes get shared amongst other developers, and enter into the testing system, so problems on more obscure platforms get found earlier, and problems that the changes cause other libraries can be detected. It also means more of the historical test results appear in the boostorg repo.

For what it's worth, I do all of my development on branches in forks, but we also have to work with the boostorg organisation as a collaborative location. We already have enough problems tracking changes in different libraries, making it harder is a bad idea.

I don't think anyone was proposing not to have develop on boostorg, I think they were proposing not having 5000 branches of new features actively under development on boost. Authors can make their local tests/commits to develop/test a feature on their account and then push that feature to the develop branch on boostorg. Develop should be for testing of features before they find their way into master anyway. If I am working on a new feature/bugfix I don't want to be working on someones ultra-unstable personal branch.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 27/08/2017 18:02, Peter Dimov via Boost wrote:

Gary Furnish wrote:

...

I don't think anyone was proposing not to have develop on boostorg, I think they were proposing not having 5000 branches of new features actively under development on boost.

That's not a problem we're having at the moment. Our immediate blocker last time I took a look were the pull requests against boostorg/math. Math had many OS X jobs, which were taking quite a while.

Ugh, sorry. If that's the blocker I'll see if I can whittle them down: part of the issue is that the full Math tests take too long to run as one block, so they're actually split into 5 blocks. BTW, we already have a fine array of volunteer testers, is there any way of setting up our own private CI system - is the software used by Travis and Appveyor open source? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com