On 11/11/2011 9:27 PM, Vladimir Panteleev wrote:
> On Sat, 12 Nov 2011 07:15:06 +0200, Brad Roberts <braddr at puremagic.com> wrote:
>
>> They already are!  The auto-tester does nothing beyond running the dmd, druntime, and phobos unit tests.
>
> Your auto-tester also runs on a much larger variety of platforms than is available to most contributors.

Yes, which is part of the point of it being available to pull developers. Though I suspect this can be a security issue, as they'll be running arbitrary code :-(

On 11/11/2011 10:03 PM, Walter Bright wrote:
>
>
> On 11/11/2011 9:27 PM, Vladimir Panteleev wrote:
>> On Sat, 12 Nov 2011 07:15:06 +0200, Brad Roberts <braddr at puremagic.com> wrote:
>>
>>> They already are! The auto-tester does nothing beyond running the dmd, druntime, and phobos unit tests.
>>
>> Your auto-tester also runs on a much larger variety of platforms than is available to most contributors.
>
> Yes, which is part of the point of it being available to pull developers. Though I suspect this can be a security issue, as they'll be running arbitrary code :-(

What Daniel did, a white list of github user id's, is a good enough level of protection.  By the end of this weekend I'll have the pull tester running on my fleet of machines, so we'll get testing across the majority of supported set of platforms.

On 11 November 2011 19:42, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 11/11/11 12:22 PM, Walter Bright wrote:
>>
>> It usually takes a couple hours to merge a patch, if things go smoothly. Most of that is running the test suite.
>
> That suggests a simple investment of money in bigger iron could have a large positive impact on the development pace. This is NOT the time to be stingy, as being penny wise now means we're negatively impacting D's future - perhaps irreversibly. Walter, I'm ready to pay 50% of whatever machine you want to buy. Please contact me for details.

I also think patches like
https://github.com/D-Programming-Language/dmd/pull/437
which address bottlenecks in compilation speed, are also very helpful.
If we compilation speed improves, it benefits everybody.

On 11/11/2011 10:14 PM, Brad Roberts wrote:
>
> What Daniel did, a white list of github user id's, is a good enough level of protection.  By the end of this weekend I'll have the pull tester running on my fleet of machines, so we'll get testing across the majority of supported set of platforms.
>

I'm working on 64 bit OS X generation, so add that to your plans.

On 11/11/2011 11:43 PM, Walter Bright wrote:
>
>
> On 11/11/2011 10:14 PM, Brad Roberts wrote:
>>
>> What Daniel did, a white list of github user id's, is a good enough level of protection. By the end of this weekend I'll have the pull tester running on my fleet of machines, so we'll get testing across the majority of supported set of platforms.
>>
>
> I'm working on 64 bit OS X generation, so add that to your plans.

Will it be like linux in that it can do the full mess of 32/64 combinations or more like freebsd with just purely 32 or purely 64?  Either way, trivial to add them.. a little copy an pasting.

On 12 nov 2011, at 06:38, Vladimir Panteleev wrote:

> On Sat, 12 Nov 2011 06:58:16 +0200, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> 
>> Git in general doesn't have a way to unpull AFAIK, which would make it rather hard for github to do it.
> 
> What about reverting the merge commit?
> 
> git revert -m 1 <merge-commit-SHA1>
> 
> -- 
> Best regards,
> Vladimir                            mailto:vladimir at thecybershadow.net
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals


I would say it's better to not pull on github in the first place. Pull and verify on the local machine instead.

-- 
/Jacob Carlborg

There's a github tool available for Mac OS X that makes testing pull request very simple, if I recall correctly.

http://mac.github.com/ https://github.com/blog/878-announcing-github-for-mac

On 12 nov 2011, at 05:06, Michel Fortin wrote:

> Le 2011-11-11 ? 22:25, Walter Bright a ?crit :
> 
>> On 11/11/2011 10:50 AM, Brad Roberts wrote:
>>> 
>>> The bigger issue, imho, is Walter's lack of trust in the automated testers.
>> 
>> Another issue is when I do a pull, and it fails testing. This just happened. Things pretty much grind to a halt when that happens. I wish github had an "unpull" button.
> 
> Then just don't use Github's pull button. Instead begin by adding a reference to the requester's github repository in your local repository:
> 
> 	git remote add {username} https://github.com/{username}/dmd.git
> 
> Then pull its code directly from it:
> 
> 	git pull {username}/{branchname}
> 
> The pull is kept local until you push it yourself. You can thus run the tests locally. Once you push those changes to Github, the pull request is automatically closed.
> 
> The interesting thing is that if you're not satisfied you can just erase the pull and no one will notice (since it was all kept local). You can erase the last commit created by the pull and return to how things were before the pull like this:
> 
> 	git reset --hard HEAD^
> 
> But don't do this if the commit was already pushed! If that's the case just revert the commit. Rewriting the publicly accessible history will causes problems for everyone (and git will complain when you try to push too). Better not push until you've determined the pull was good.
> 
> Note that if the merge had conflicts (and thus the pull was not autocommited), running the command above will erase the last commit *before* the pull, which is not what you want. You can get back to the clean state of the last commit like this:
> 
> 	git reset --hard
> 
> I probably wrote all that in too much details. I hope it is helpful though.
> 
> 
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 
> 
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

-- 
/Jacob Carlborg

On Nov 12, 2011, at 1:14 AM, Brad Roberts <braddr at puremagic.com> wrote:
> 
> What Daniel did, a white list of github user id's, is a good enough level of protection.  By the end of this weekend I'll have the pull tester running on my fleet of machines, so we'll get testing across the majority of supported set of platforms.

I've been wondering if it would be a good idea to set up a workflow where Walter does more than one pull request at a time. After testing all individual pulls, the auto tester could try testing all (passing) pulls from a single author all applied on top of each other. If that larger test passes, then maybe it could save several steps for Walter by handling multiple pull requests at once?

On 11/11/2011 11:48 PM, Brad Roberts wrote:
> On 11/11/2011 11:43 PM, Walter Bright wrote:
>>
>>
>> I'm working on 64 bit OS X generation, so add that to your plans.
>
> Will it be like linux in that it can do the full mess of 32/64 combinations or more like freebsd with just purely 32 or purely 64?  Either way, trivial to add them.. a little copy an pasting.
>

At the moment, do all 4 combinations.

Though we'll probably abandon 32 bit dmd executables.

On 11/12/2011 6:23 AM, Jason House wrote:
>
> I've been wondering if it would be a good idea to set up a workflow where Walter does more than one pull request at a time. After testing all individual pulls, the auto tester could try testing all (passing) pulls from a single author all applied on top of each other. If that larger test passes, then maybe it could save several steps for Walter by handling multiple pull requests at once?

I've avoided multiple pulls at once, because when they fail it's just miserable.