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 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
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 reply "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
parent reply 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
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
prev 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 parent reply 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
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


 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.


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 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 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