On 1/6/2013 6:32 PM, Walter Bright wrote:
> 
> On 1/6/2013 5:52 PM, Jonathan M Davis wrote:
>> Ideally, yes. In reality, it would probably be a problem. We have plenty of problems with reviews being a bottleneck already. However, even if no one else reviews your pull requests, simply going through the process of creating a pull request and letting the pull tester test it will prevent problems involving files being forgotten or breaking platforms that you don't necessarily test on. And if you _do_ test them all already, then maybe the pull request will save you some of that effort. But it doesn't seem to be all that uncommon that you end up having to make commits to unbreak the build because you forgot to commit a file. And using pull requests would catch all that sort of stuff. It would also make sure that it's all working on machines other than your own. - Jonathan M Davis
> 
> I test on all platforms here except FreeBSD64. I have a nice build farm in the basement :-)

Costing a lot of time in the process, and still not catching the not infrequent failure to remember a file.  Adding those machines to the tester-farm and using the tester would be a net win for all changes.

> Yeah, I forget to push a file once in a while. And then I fix it.

Sometimes a day later, which is highly annoying and completely avoidable.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/6/2013 6:31 PM, Brad Roberts wrote:
> 3) There's more value to pull requests than just human review, the auto-tester adds value too.

I agree the auto-tester adds value. I think it has been a huge success in enabling a diverse group of people to contribute to D.

But since I run the tests anyway on my own build farm, I don't think it adds as much value in this particular case.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/6/2013 6:44 PM, Brad Roberts wrote:
> Sometimes a day later, which is highly annoying and completely avoidable.
>
>

Yeah, that is a problem, sometimes I don't notice that it failed.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Jonathan M Davis, el  6 de January a las 17:52 me escribiste:
> On Sunday, January 06, 2013 17:45:27 Walter Bright wrote:
> > On 1/6/2013 5:08 PM, Jonathan M Davis wrote:
> > > Even if you were merging all of your pull requests for dmd yourself rather than waiting for reviews like everyone else does, by using pull requests, you'd at least avoid breaking the build due to forgetting to commit everything, and you'd get your changes tested on all of our platforms by the pull tester. I don't see any reason for you not to do at least do that much, and I thought that that's what you had previously agreed to start doing.
> > I did agree to the release process, which is what we did.
> > 
> > I do several commits a day, this easily moves into hundreds for each cycle. Is anyone going to review them?
> 
> Ideally, yes. In reality, it would probably be a problem. We have plenty of problems with reviews being a bottleneck already.
> 
> However, even if no one else reviews your pull requests, simply going through the process of creating a pull request and letting the pull tester test it will prevent problems involving files being forgotten or breaking platforms that you don't necessarily test on. And if you _do_ test them all already, then maybe the pull request will save you some of that effort. But it doesn't seem to be all that uncommon that you end up having to make commits to unbreak the build because you forgot to commit a file. And using pull requests would catch all that sort of stuff. It would also make sure that it's all working on machines other than your own.

And I noticed you (Walter) talked in favor of git bisect recently (I don't remember where, maybe a bug report). Each time you break the repository with a commit that doesn't work, you're making using git bisect harder.

At least go through the autotester so we can have painless git bisections :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
They love me like I was a brother
They protect me, listen to me
They dug me my very own garden
Gave me sunshine, made me happy

Nice dream, nice dream
Nice dream
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  6 de January a las 19:22 me escribiste:
> 
> On 1/6/2013 6:31 PM, Brad Roberts wrote:
> >3) There's more value to pull requests than just human review, the auto-tester adds value too.
> 
> I agree the auto-tester adds value. I think it has been a huge success in enabling a diverse group of people to contribute to D.
> 
> But since I run the tests anyway on my own build farm, I don't think it adds as much value in this particular case.

It's been pointed out several times, to avoid breaking the repository.

What I don't understand is, having all the infrastructure already set up for you, why do you still want to use your own. Is an incredible duplication of work!

From what I see, using your own farm (which is clearly less polished than the auto tester because you are not testing clean checkouts, but you own working copy) is more work for everybody (including you) and more error prone.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si le decía "Vamos al cine, rica"
Me decía "Veamos una de Kusturica"
Si le decía "Vamos a oler las flores"
Me hablaba de Virginia Wolf y sus amores
Me hizo mucho mal la cumbiera intelectual
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/7/13 10:03 AM, Leandro Lucarella wrote:
> Walter Bright, el  6 de January a las 19:22 me escribiste:
>>
>> On 1/6/2013 6:31 PM, Brad Roberts wrote:
>>> 3) There's more value to pull requests than just human review, the
>>> auto-tester adds value too.
>>
>> I agree the auto-tester adds value. I think it has been a huge
>> success in enabling a diverse group of people to contribute to D.
>>
>> But since I run the tests anyway on my own build farm, I don't think
>> it adds as much value in this particular case.
>
> It's been pointed out several times, to avoid breaking the repository.

That's not the matter. Walter's code needs to go through the review process.

Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/7/2013 9:57 AM, Leandro Lucarella wrote:
> And I noticed you (Walter) talked in favor of git bisect recently (I don't remember where, maybe a bug report). Each time you break the repository with a commit that doesn't work, you're making using git bisect harder. At least go through the autotester so we can have painless git bisections :) 

Yeah, that is an advantage.

I talked about git bisect in the context of replacing druntime functions with compiler internal generation, but leaving the druntime functions in for the time being in order to support using git bisect.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/7/2013 10:03 AM, Leandro Lucarella wrote:
> It's been pointed out several times, to avoid breaking the repository.

Yes, I do understand that.

> What I don't understand is, having all the infrastructure already set up for you, why do you still want to use your own. Is an incredible duplication of work!

Well, if it breaks on Brad's build farm, I can't debug it. I need my own setup to debug it.

>
>  From what I see, using your own farm (which is clearly less polished than the
> auto tester because you are not testing clean checkouts, but you own working
> copy) is more work for everybody (including you) and more error prone.


Not so clear from my point of view. When I did the last release, working with two branches at the same time (staging and master), back and forth, I had a lot of mental confusion keeping track of which of my machines had which version of the code on it.

With doing dmd fixes as pull requests, I wind up with two git repositories for dmd. One is the 'master', which is linked to the main dmd github repository. Then, I have another git repository linked to my personal github account which I use to do forks and pull requests from.

I.e. I haven't figured out how to do pull requests from the repository linked to github d-p-l, and I haven't figured out how to push to github d-p-l from the walterbright fork, if it is even possible. It makes my brain hurt even thinking about it.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  7 de January a las 12:39 me escribiste:
> >What I don't understand is, having all the infrastructure already set up for you, why do you still want to use your own. Is an incredible duplication of work!
> 
> Well, if it breaks on Brad's build farm, I can't debug it. I need my own setup to debug it.

Yes you can, but is true that it can be a little more work. But then, you can use both, you will catch most of the problems with your local tests, and other problems with the auto tester, and everybody is happy :)

Remeber that queueing some pull request to be tested by the auto tester doesn't stop you from continue your work if you use local branches for different topics you're working on.

> > From what I see, using your own farm (which is clearly less polished than the
> >auto tester because you are not testing clean checkouts, but you own working
> >copy) is more work for everybody (including you) and more error prone.
> 
> Not so clear from my point of view. When I did the last release, working with two branches at the same time (staging and master), back and forth, I had a lot of mental confusion keeping track of which of my machines had which version of the code on it.

Mmm, with "my machines" you're refering to your farm? In that case letting the auto tester make that for you wouldn't be a huge win?

> With doing dmd fixes as pull requests, I wind up with two git repositories for dmd. One is the 'master', which is linked to the main dmd github repository. Then, I have another git repository linked to my personal github account which I use to do forks and pull requests from.

Exactly. You shouldn't even need to clone the "master" repository (the organization's repository to follow github terms), at least not if you're merging pull requests using the "Merge" button in the web interface.

> I.e. I haven't figured out how to do pull requests from the repository linked to github d-p-l, and I haven't figured out how to push to github d-p-l from the walterbright fork, if it is even possible. It makes my brain hurt even thinking about it.

I'd like to help you but I have to understand what you're trying to do. Do you have also 2 github accounts? Or you have only one as the owner of the organization? Also, are you doing any pull request merging using your local cloned repository and then pushing the changes to the remote organization's repository, or are you just using the "Merge" button in the web interface?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<mazzi> Estoy en berlin
<mazzi> Es como palermo
<mazzi> Pero
<mazzi> Mas copado
<mazzi> Muuucho menos careta
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/7/2013 3:58 PM, Leandro Lucarella wrote:
>> I.e. I haven't figured out how to do pull requests from the
>> repository linked to github d-p-l, and I haven't figured out how to
>> push to github d-p-l from the walterbright fork, if it is even
>> possible. It makes my brain hurt even thinking about it.
> I'd like to help you but I have to understand what you're trying to do. Do you
> have also 2 github accounts? Or you have only one as the owner of the
> organization? Also, are you doing any pull request merging using your local
> cloned repository and then pushing the changes to the remote organization's
> repository, or are you just using the "Merge" button in the web interface?

One git on my local machine is synced with my github account, WalterBright, which is a fork. The other is the one created as part of creating the dmd repository under d-programming-language.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals