www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - =?UTF-8?B?wrtIYXNrZWxs?= vs. =?UTF-8?B?RMKr?= backstage discussion

reply "David Nadlinger" <see klickverbot.at> writes:
Another video from Lang.NEXT 2012 went live recently: [1]. Erik 
Meijer is joined by Andrew Adams-Moran, Walter and Andrei to 
discuss various topics surrounding D and Haskell. Most of the 
things covered probably aren't particularly new to most of the 
people here, but publicity for D is alway nice to see (also don't 
miss Andrei's humorous remark on the editor war).

One topic I found very interesting, but which was unfortunately 
barely covered within the constrained time, is the question about 
what »dirty laundry« is there for D, the language, right now 
(i.e. features/aspects that turned out to be more of a liability 
than profit). Sure, bit is an example, but that has been disposed 
of a long time ago. What has piled up in the basket since then?

David


[1] 
http://channel9.msdn.com/Blogs/Charles/Alexandrescu-Bright-Meijer-Moran-Pure-versus-Native-and-much-more
Apr 17 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:

 http://channel9.msdn.com/Blogs/Charles/Alexandrescu-Bright-Meijer-Moran-Pure-versus-Native-and-much-more

Good chat, but too much short :-) Compared to the others Walter seems a less noisy person. D language surely has some things to learn from Haskell (like its syntax sugar for tuples usage). I think the problem of ~100 open pull requests needs to be faced better. People that see their patches rot in that list probably don't feel rewarded enough to submit more patches. Bye, bearophile
Apr 17 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 18-04-2012 11:00, Trass3r wrote:
 I think the problem of ~100 open pull requests needs to be faced
 better. People that see their patches rot in that list probably don't
 feel rewarded enough to submit more patches.

So true. I won't do any further work if it's in vain anyway. Also I regularly have to rebase my one cause of conflicts, which is annoying. I really wonder what Walter's doing. Is he still running the whole testsuite instead of relying on the autotester?

Just looking at the auto tester, there seems to be tons of stuff that can readily be merged... -- - Alex
Apr 18 2012
parent reply Don Clugston <dac nospam.com> writes:
On 18/04/12 12:19, Alex Rønne Petersen wrote:
 On 18-04-2012 11:00, Trass3r wrote:
 I think the problem of ~100 open pull requests needs to be faced
 better. People that see their patches rot in that list probably don't
 feel rewarded enough to submit more patches.

So true. I won't do any further work if it's in vain anyway. Also I regularly have to rebase my one cause of conflicts, which is annoying. I really wonder what Walter's doing. Is he still running the whole testsuite instead of relying on the autotester?

Just looking at the auto tester, there seems to be tons of stuff that can readily be merged...

One problem is github. IMHO github's pull requests are quite ridiculous, there is no way to prioritize them. There are quite a lot of pull requests in there which are doubtful, high-risk, or require a lot of time to evaluate. Currently, we don't have a way to deal with them. But, the announce list is not the appropriate place for this discussion. Please move to the main list if you want to comment further.
Apr 18 2012
parent Don Clugston <dac nospam.com> writes:
On 19/04/12 16:58, David Nadlinger wrote:
 On Wednesday, 18 April 2012 at 10:39:26 UTC, Don Clugston wrote:
 One problem is github. IMHO github's pull requests are quite
 ridiculous, there is no way to prioritize them.

You can't blame GitHub for something we are not using it for – pull request, as far as we are using them, are just a tool to keep patches close to the source so that they can conveniently be reviewed and merged.

If that is so, then this thread is invalid -- the number of open pull requests is not a useful metric. Issue tracking, prioritization, etc. all happens on Bugzilla,
 and every pull request should have an accompanying »pull«-tagged
 Bugzilla entry.

 The infrastructure is already there,

Is it? I can't see any method for dealing with patches that aren't merged immediately. We have bugzilla as a priority system for bugs without patches, github works for submitting patches, and a great infrastructure for testing the compiler after patches are merged (thanks Brad!) but the patch evaluation step (specifically, the "code review" part) is missing.
Apr 23 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2012 9:00 PM, bearophile wrote:
 I think the problem of ~100 open pull requests needs to be faced better. People
 that see their patches rot in that list probably don't feel rewarded enough to
 submit more patches.

Consider that 8 out of 9 submitted pull requests for dmd have been pulled, and the current unpulled list does not include solutions for issues people are regarding as critical blockers.
Apr 18 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 I think the problem of ~100 open pull requests needs to be faced better.  
 People that see their patches rot in that list probably don't feel  
 rewarded enough to submit more patches.

So true. I won't do any further work if it's in vain anyway. Also I regularly have to rebase my one cause of conflicts, which is annoying. I really wonder what Walter's doing. Is he still running the whole testsuite instead of relying on the autotester?
Apr 18 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 18/04/2012 00:49, David Nadlinger a écrit :
 Another video from Lang.NEXT 2012 went live recently: [1]. Erik Meijer
 is joined by Andrew Adams-Moran, Walter and Andrei to discuss various
 topics surrounding D and Haskell. Most of the things covered probably
 aren't particularly new to most of the people here, but publicity for D
 is alway nice to see (also don't miss Andrei's humorous remark on the
 editor war).

 One topic I found very interesting, but which was unfortunately barely
 covered within the constrained time, is the question about what »dirty
 laundry« is there for D, the language, right now (i.e. features/aspects
 that turned out to be more of a liability than profit). Sure, bit is an
 example, but that has been disposed of a long time ago. What has piled
 up in the basket since then?

 David


 [1]
 http://channel9.msdn.com/Blogs/Charles/Alexandrescu-Bright-Meijer-Moran-Pure-versus-Native-and-much-more

yum on debian systems ????
Apr 18 2012
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 18 April 2012 at 17:05:08 UTC, Walter Bright wrote:
 On 4/17/2012 9:00 PM, bearophile wrote:
 I think the problem of ~100 open pull requests needs to be

 that see their patches rot in that list probably don't feel

 submit more patches.

Consider that 8 out of 9 submitted pull requests for dmd have been pulled, and the current unpulled list does not include solutions for issues people are regarding as critical blockers.

It might be a good policy to have the submitter (or even yourself) close pull requests that aren't ready for merging and reopen them once they are ready to be reviewed. This would help make the queue more manageable and easier to see what's ready to consider and what is not (it's a shame pull requests don't have simple tagging/labeling like GitHub's issues). Regards, Brad Anderson
Apr 18 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 18 April 2012 at 17:05:08 UTC, Walter Bright wrote:
 Consider that 8 out of 9 submitted pull requests for dmd have 
 been pulled

Another thing to consider is some of them are waiting for other reasons. My pull requests, for example, are waiting on ME to address a comment and I haven't gotten around to it yet. I don't think you can tell that by looking at it in github. Who knows how many others are in a similar condition.
Apr 18 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 18 April 2012 at 09:00:59 UTC, Trass3r wrote:
 I think the problem of ~100 open pull requests needs to be 
 faced better. People that see their patches rot in that list 
 probably don't feel rewarded enough to submit more patches.

So true. I won't do any further work if it's in vain anyway. Also I regularly have to rebase my one cause of conflicts, which is annoying. I really wonder what Walter's doing. Is he still running the whole testsuite instead of relying on the autotester?

Well, I've seen at least one regression in D.learn from 2.058 to 2.059 and that doesn't give me much confidence in what random people are doing when they are submitting their patches. So instead of bitching about what Walter's doing, people should be more careful what THEY are doing.
Apr 18 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 18 April 2012 at 10:39:26 UTC, Don Clugston wrote:
 One problem is github. IMHO github's pull requests are quite 
 ridiculous, there is no way to prioritize them.

You can't blame GitHub for something we are not using it for – pull request, as far as we are using them, are just a tool to keep patches close to the source so that they can conveniently be reviewed and merged. Issue tracking, prioritization, etc. all happens on Bugzilla, and every pull request should have an accompanying »pull«-tagged Bugzilla entry. The infrastructure is already there, Walter (and the rest of us) just need to use it more aggressively – and if not, determine what exactly is wrong with it in terms of productivity, instead of just randomly blaming our tools. David
Apr 19 2012
prev sibling parent "foobar" <foo bar.com> writes:
On Monday, 23 April 2012 at 11:46:50 UTC, Don Clugston wrote:

 The infrastructure is already there,

Is it? I can't see any method for dealing with patches that aren't merged immediately. We have bugzilla as a priority system for bugs without patches, github works for submitting patches, and a great infrastructure for testing the compiler after patches are merged (thanks Brad!) but the patch evaluation step (specifically, the "code review" part) is missing.

There is an open source code review tool that integrates with git called Gerrit. It is used by Google for Android and other large code bases comprised of several git repositories. I think it's closer to Walter's way of managing code.
Apr 23 2012