FWIW, I have a Gentoo x86-64 machine standing around doing practically nothing. If it can be put to use for auto-testing, let me know.

Regards,
Alex

On Fri, Nov 11, 2011 at 7:50 PM, Brad Roberts <braddr at puremagic.com> wrote:
> On 11/11/2011 10:42 AM, Andrei Alexandrescu 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.
>>
>> Kenji's post is symptomatic of a problem that I wished we'd have for a long time, and that I figured a few months ago it's inevitable: the bottleneck is not lack of contributions anymore, it's process and logistics.
>>
>> Walter, we should discuss improving these areas ASAP.
>>
>>>> Please answer this question, Walter. I'd like to improve the bottleneck.
>>>
>>> I'd like to compliment you on how prolific, helpful, and correct your patches have been. Thanks!
>>
>> I'd like to join Walter, too, but let me also point out that in addition
>> to thanking him, we need to *really* answer
>> Kenji's question with a concerted course of action.
>>
>>
>> Thanks,
>>
>> Andrei
>
> The bigger issue, imho, is Walter's lack of trust in the automated testers. ?If they're insufficient, then lets talk about what it will take to make them sufficient. ?They can and will keep way ahead of Walter's individual test runs. Bigger hardware under his desk (or in a closet or in the basement) is the wrong approach, imho.
>
> We've got Daniel's pull tester here: http://yebblies.com/results/
>
> I'm working on incorporating it in to my system so they're will be more
> parallelism (multiple boxes) and multiple platforms (all of them, ideally).
>
> With trust in the tester, that eliminates hours of time from each pull
> request.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On Fri, 11 Nov 2011, Andrei Alexandrescu wrote:

> On 11/11/11 1:05 PM, Brad Roberts wrote:
> > Also, if bigger iron is the preferred path, I'll pay all the costs for a c1.xlarge ec2 instance. It's not the fastest box on the market (pre Nehalem), but it's a good price/performance box. 8 cores, with plenty of memory and disk. Using the spot market and assuming an average of 5 hours a day of usage, it'd only cost about $30/month. If faster cores are desired, they're available, just cost more. But paid at hourly actual use rates, would still cost less than buying a box that's not used full time.
> 
> I think that's a terrific offer that we should take. Thanks, Brad! Also it's not about an either-or choice; improvements in both automated testing AND efficient testing should pay off handsomely.
> 
> Andrei
> 

I agree it's not entirely either-or, but I think breaking Walter's habit of not trusting the auto-testers to do the validation that he spends hours on is much more important.

Sorry for talking about you in the third person Walter, but I really do feel that it's your development process needs to change to speed up the rate of progress of dmd itself.  Just throwing bigger hardware at it isn't the best answer.

It really doesn't even take all that much iron. The OSX test box is a previous-generation Mac Mini and it's far faster than the other test machines. I bet you could have 2-3 fast test boxes for under $1000 if you were willing to get mini tower PCs.

Sent from my iPhone

On Nov 11, 2011, at 10:42 AM, 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.
> 
> Kenji's post is symptomatic of a problem that I wished we'd have for a
> long time, and that I figured a few months ago it's inevitable: the
> bottleneck is not lack of contributions anymore, it's process and logistics.
> 
> Walter, we should discuss improving these areas ASAP.
> 
>>> Please answer this question, Walter. I'd like to improve the bottleneck.
>> 
>> I'd like to compliment you on how prolific, helpful, and correct your patches have been. Thanks!
> 
> I'd like to join Walter, too, but let me also point out that in addition to thanking him, we need to *really* answer Kenji's question with a concerted course of action.
> 
> 
> Thanks,
> 
> Andrei
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

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.

On 11/11/2011 11:12 AM, Andrei Alexandrescu wrote:
>
> I think that's a terrific offer that we should take. Thanks, Brad! Also it's not about an either-or choice; improvements in both automated testing AND efficient testing should pay off handsomely.
>

Would such a tester be available for those submitting patches so they can run the autotester *before* an attempt is made to merge?

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/

I am ignorant about the interface with github, but can't you use git-reset to undo?

Sent from my iPhone

On Nov 11, 2011, at 10:25 PM, Walter Bright <walter at digitalmars.com> wrote:

> 
> 
> 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.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/11/2011 8:22 PM, Jason House wrote:
> I am ignorant about the interface with github, but can't you use git-reset to undo?
>

I don't know.

On Friday, November 11, 2011 19:25:59 Walter Bright wrote:
> 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.

Git in general doesn't have a way to unpull AFAIK, which would make it rather hard for github to do it.

Probably the correct way to handle this if you're trying to avoid ever merging in bad pulls is to simply not use the pull button - or at least not use it immediately. If you merge the request in manually into a branch on your local machine, you can test it there.

For instance, if Kenji had a pull request on a branch named fix, then you could do this (9rnsr is Kenji's github ID):

git-checkout -b fix
git-pull git://github.com/9rnsr/dmd fix

This creates a local branch named fix and pulls in Kenji's changes. You then run the test suite or whatever else you do to verify the fix. After you're sure that they're good, you then either use the button on github or merge the fix branch into your master branch and push that into the master repository.

But unfortunately, I'm not aware of any way to automate unmerging. If you determined which commits they were, you could revert them one by one, but that's the best that I'm aware of - especially if you don't want to rebase (which would be very bad to do with the main repository, since that would screw up everyone's forks).

- Jonathan M Davis

On Sat, Nov 12, 2011 at 4:18 AM, kenji hara <k.hara.pg at gmail.com> wrote:
> - Conflicting?
> ?Almost patches uses runnable/xtest46.d, template9.d, aliasthis.d
> for test suite. This fact has introduced conflicts between the
> patches. I sometimes rebases my many pulls, but the cost of doing it
> is much more.
>

In most of my patches, I've been inserting the test functions and function calls in random places in xtest46.d.  Before, I had to rebase 20+ pull requests every time xtest46 was modified, and I've never had to rebase one for this reason since.  You should probably do the same.

The main reason I made the pull request autotester was to automatically find trivial merge conflicts for me, turning a multi-hour scan of the open pull requests into 5 minutes per pull request for a trivial rebase+edit.


> Walter wrote:
> 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.
> Would such a tester be available for those submitting patches so they can run the autotester *before* an attempt is made to merge?

There already is a tester available for all open pull requests:
http://yebblies.com/results/
Although it's linux32 only, and not particularly fast, pull requests
that fail on there should never be pulled.