Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: There's a lot of technical debt I've been trying to fix with that, and nobody else seems willing to do it. For example, fixing the error messages so they make use of color syntax highlighting. It's boring, tedious, unfun work, meaning I get to do it :-) Another issue is I've had the flu for a while which makes me tired, and then it's best to work on things that don't require much mental energy. (Yes, I got the flu shot, and the durned thing did not work.) Afaik, the flu shot only covers those viruses that are arlready known to scientists (which only makes sense). Since the darn things keep mutating all the time, we have to deal with new strains every year. So one could argue that the flu shots are only of limited usefulness. Maybe a new strain attacked you, and maybe, consciously or subconsciously, people who got the shot behave more carelessly, (wrongly) assuming that they are immune to the flu.
Re: Some Observations on the D Development Process
On 1/9/2018 6:53 PM, Mike Franklin wrote: I couldn't find any cases like that. If you know of them, please explicitly identify them for me. I already fixed them.
Re: Some Observations on the D Development Process
On 01/11/2018 02:15 PM, Johan Engelen wrote: And I've been working for a long time on a fuzzing article. It's almost done! - Johan A fuzzy font would suit that article. :o) Ali
Re: Some Observations on the D Development Process
On Wednesday, 10 January 2018 at 05:46:04 UTC, Nicholas Wilson wrote: On Sunday, 7 January 2018 at 16:52:55 UTC, Random D user wrote: While not directly applicable to 'technical debt', has anyone ever written a fuzzer for dmd? Johan Engelen has used LLVM libFuzzer on it. And I've been working for a long time on a fuzzing article. It's almost done! - Johan
Re: Some Observations on the D Development Process
On Sunday, 7 January 2018 at 16:52:55 UTC, Random D user wrote: While not directly applicable to 'technical debt', has anyone ever written a fuzzer for dmd? Johan Engelen has used LLVM libFuzzer on it.
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote: On 1/4/2018 9:44 AM, Jack Stouffer wrote: DMD also has at least 30 PRs which have had no action from the author in over a year. There's no reason these should be kept open; they just take up auto-tester resources and lower the signal to noise ratio. If the author comes back later, they can always ask a maintainer to reopen. I can't agree with the "just close older bugs and PRs." There's good stuff in them. Even if the PR is no good, it provides insight to someone working on a better fix. Closing it means nobody will ever be aware of it or look at it again. Sure, by surfing through 100-s of stalled PRs among real active work. Somebodies archive currently is a burndown list of others. That can’t be good and is highly frustrating. What I’m saying is that closing PR doesn’t evaporate it. Mark as stalled and close. If someone is on treasure hunting, just click closed PRs and add ‘stalled’ tag to search. Relying on the original author to revive it will not work. Then by definition PR won’t get merged in the first place. It takes a fair amount of motivation and busy work by author even when all is good. If we can’t merge it, why keep it around as OPEN? It's similar with older bugs. They still have discussion on them that contributes valuable information and insight to anyone wishing to work on it. Closing them with no action means the information is all lost. Piling them in bugzilla has the same downside - actionable items are intermingled with some “archived” and largely irrelevant non-actionable stuff. Bugzilla is though a lost case, so I will not suggest to move anything there.
Re: Some Observations on the D Development Process
On Saturday, 6 January 2018 at 02:53:38 UTC, Walter Bright wrote: For example, there were several uses of the word 'ctor' instead of 'constructor'. I couldn't find any cases like that. If you know of them, please explicitly identify them for me. Thanks, Mike
Re: Some Observations on the D Development Process
On 7 January 2018 at 17:52, Random D user via Digitalmars-d wrote: > On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: >> >> On 1/4/2018 2:34 AM, Mike Franklin wrote: >>> >>> Walter seems to pop in daily, and occasionally reviews PRs, and his PRs >>> of late are mostly just refactorings rather than fixing difficult bugs. >> >> There's a lot of technical debt I've been trying to fix > > > While not directly applicable to 'technical debt', has anyone ever written a > fuzzer for dmd? > Yes, its called Defuzzed.
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: On 1/4/2018 2:34 AM, Mike Franklin wrote: Walter seems to pop in daily, and occasionally reviews PRs, and his PRs of late are mostly just refactorings rather than fixing difficult bugs. There's a lot of technical debt I've been trying to fix While not directly applicable to 'technical debt', has anyone ever written a fuzzer for dmd? Basically a testing software that generates valid or almost valid (negative case) input (code using grammar rules) and tries to run it through the application (compiler) to see what happens. These things usually reveal tons of easy to fix bugs at the application interface level and some hard to fix corner cases that no one thought. Best of all, you will get easy to use test cases that some else can try to fix. Unfortunately fuzzers often get stuck in local maximums, so you need to spend some time with app coverage using the generated data and modify the fuzzer accordingly. But once it has been built and it tests large code coverage, it's an awesome tool to reveal bugs and test changes. Just make a change, run tests, run fuzzer for 5-15 mins, 1h or days if you want extra coverage. I think there's also a variant of this that takes valid code and replace existing code constructs with equivalent but unusual constructs.
Re: Some Observations on the D Development Process
On Fri, 05 Jan 2018 18:53:38 -0800, Walter Bright wrote: > On 1/5/2018 7:39 AM, Seb wrote: >> We should put things like this somewhere where it can easily be seen by >> others. >> The obvious candidates are the Wiki and Bugzilla, but both have >> historically proven to yield poor results, e.g. > > Sigh. Bugzilla is the answer, and lots of people do troll Bugzilla > looking for things to do. Adding another list somewhere else is not > going to improve things. Note that Andrei (I think) set up a "bootcamp"[1] keyword on bugzilla for easy issues a while back; the problem has been solved though maybe not advertised consistently. The wiki's "Get Involved" page includes a link to preapproved and bootcamp issues. CONTRIBUTING.md also links to it - maybe it's just on the forums nobody talks about it... [1]: https://issues.dlang.org/buglist.cgi? component=dmd&keywords=bootcamp&product=D
Re: Some Observations on the D Development Process
On 1/5/2018 7:41 AM, H. S. Teoh wrote: I'm sad that it has to fall upon Walter to do these routine, mundane, tedious work, when we greatly need his expertise elsewhere in D land. Walter, what about posting a list of boring, tedious stuff that has landed on your plate somewhere, so that those of us looking for something to do can pick it up? I posted some in reply to Mike in this thread. Mike has taken up the cudgel and is submitting a flurry of PRs! :-) Here's more: 1. try to reduce dependency of code on global variables 2. add missing/inadequate/incomplete Ddoc comments to functions 3. each source file now has a direct link at the top to the coverage report for it. Devise additions to the test suite to improve coverage
Re: Some Observations on the D Development Process
On 1/4/2018 10:20 PM, Patrick Schluter wrote: The only people I ever saw with a flu (I mean a real influenza) had all one thing in common: they all had gotten the flu shot. There was a 3 month gap between the shot and getting the flu, so there's no credible connection. I haven't gotten the flu in other years when I got the shot, even when unshot others were felled all around me :-) I'm certainly going to continue getting the annual shot. I just rolled the dice this year and lost.
Re: Some Observations on the D Development Process
On 1/5/2018 7:39 AM, Seb wrote: We should put things like this somewhere where it can easily be seen by others. The obvious candidates are the Wiki and Bugzilla, but both have historically proven to yield poor results, e.g. Sigh. Bugzilla is the answer, and lots of people do troll Bugzilla looking for things to do. Adding another list somewhere else is not going to improve things. What's needed (from my perspective) is more people doing quality work. Not more process. Mike Franklin is a standout here. He's actually going through the files I listed and has already posted several PRs doing the modifications. That is what we need. -- Now, in my work highlighting error messages, I noticed that a number of them could be made better by relying less on compiler jargon and having a bit more exposition on what the problem is. For example, there were several uses of the word 'ctor' instead of 'constructor'. There are also uses of 'aggregate' instead of 'struct, union or class'. These kind of improvements cannot be done en masse, because someone has to look at each specific message, the context which will generate it, and think about how better to express this to the user. A good message will present the context, what is wrong, and perhaps suggest corrective action. Some messages are generic for a diverse collection of actual errors, and should be broken out into different messages for each error. This has been done already for many messages, such as the ones where I added spell checking so the message could suggest what might have been meant instead, but there are an awful lot of messages in the compiler which are workmanlike, but are a bit abrupt.
Re: Some Observations on the D Development Process
On 1/5/2018 6:26 AM, Adam D. Ruppe wrote: For my projects, even if a PR isn't perfect, unless it is just plain bad or goes in a direction I strongly disagree with, I'll merge it anyway pretty quickly and just fix up the bits I don't like later myself. So if something is OK but not great don't close it, merge it! Just fix it up after and leave a note for the original PR author showing your fixup commit so they can learn from it next time. The compiler is far too complex for that. It increases the technical debt. I have pulled many PRs like that, and they've just resulted in regressions and even more work for me to do.
Re: Some Observations on the D Development Process
On Thu, Jan 04, 2018 at 07:28:10PM -0800, Walter Bright via Digitalmars-d wrote: > On 1/4/2018 2:34 AM, Mike Franklin wrote: > > Walter seems to pop in daily, and occasionally reviews PRs, and his > > PRs of late are mostly just refactorings rather than fixing > > difficult bugs. > There's a lot of technical debt I've been trying to fix with that, and > nobody else seems willing to do it. For example, fixing the error > messages so they make use of color syntax highlighting. It's boring, > tedious, unfun work, meaning I get to do it :-) [...] I'm sad that it has to fall upon Walter to do these routine, mundane, tedious work, when we greatly need his expertise elsewhere in D land. Walter, what about posting a list of boring, tedious stuff that has landed on your plate somewhere, so that those of us looking for something to do can pick it up? T -- Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 04:20:06 UTC, Walter Bright wrote:
On 1/4/2018 7:41 PM, Mike Franklin wrote:
If you have simple, mundane work that needs to be done, make a
list and send it my way; you should have my e-mail address.
But please be specific; "fix error messages" is just going to
get a reply from me asking questions.
Ok, fix error messages, like you've seen me doing already. To
find which files need work,
grep "error(" *.d
does the trick, turning up:
ctfeexpr.d
dimport.d
dinterpret.d
dscope.d
e2ir.d
expression.d
expressionsem.d
func.d
glue.d
iasm.d
mtype.d
nogc.d
nspace.d
opover.d
optimize.d
s2ir.d
as needing ` `. There's a lot of work just there :-( It's best
to resist the urge to do more than just add in ` ` where they
are obviously appropriate. Don't make perfection the enemy of
better. I've found it best to have only one PR for this at a
time, otherwise it's a lot of extra work rebasing.
A longer term goal is to find ways to refactor the code to make
maximum use of pure, const, scope, and nothrow.
I appreciate any and all help with this.
We should put things like this somewhere where it can easily be
seen by others.
The obvious candidates are the Wiki and Bugzilla, but both have
historically proven to yield poor results, e.g.
https://wiki.dlang.org/Get_involved#Contribute_to_the_DMD_and_DRuntime
So let's try something new:
https://github.com/dlang/dmd/projects/2
Note that GitHub supports two labels for issues: "help wanted"
and "good first issue" and provides many interfaces that let
interested people discover such issues.
For details:
https://help.github.com/articles/finding-open-source-projects-on-github/
https://github.com/nodejs/admin/issues/20
https://github.com/showcases/great-for-new-contributors (<- Rust
appears here)
...
Of course this only works for GitHub issues.
Re: Some Observations on the D Development Process
On 1/5/18 9:26 AM, Adam D. Ruppe wrote: On Friday, 5 January 2018 at 10:08:11 UTC, John Colvin wrote: A perfect project would be able to make quick decisions on PRs, but that doesn't mean closing PRs makes a better project. It's a little bit cargo-culty. For my projects, even if a PR isn't perfect, unless it is just plain bad or goes in a direction I strongly disagree with, I'll merge it anyway pretty quickly and just fix up the bits I don't like later myself. So if something is OK but not great don't close it, merge it! Just fix it up after and leave a note for the original PR author showing your fixup commit so they can learn from it next time. You can actually change it first before merging as a repo owner. -Steve
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 06:20:54 UTC, Patrick Schluter wrote: The only people I ever saw with a flu (I mean a real influenza) had all one thing in common: they all had gotten the flu shot. That's a case of selection bias: the people who get the shot tend to be those who are already at high risk of getting the flu. The shots cover common strains - or at least what they think will be common strains - but they don't cover all of them. So consider the math: let's say you judge yourself to have a 20% chance of getting the flu, so you get the shot. It cuts your odds by about 50%... but that still leaves you with a 10% chance of getting one of the other strains. The general population, on average, has about a 5% chance of catching the flu... so even with the shot, you, in the very high-risk pool to begin with, are still more likely to get it than the average person, but that doesn't mean the shot was ineffective, and, of course, it certainly doesn't mean the shot CAUSED it.
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 10:08:11 UTC, John Colvin wrote: A perfect project would be able to make quick decisions on PRs, but that doesn't mean closing PRs makes a better project. It's a little bit cargo-culty. For my projects, even if a PR isn't perfect, unless it is just plain bad or goes in a direction I strongly disagree with, I'll merge it anyway pretty quickly and just fix up the bits I don't like later myself. So if something is OK but not great don't close it, merge it! Just fix it up after and leave a note for the original PR author showing your fixup commit so they can learn from it next time.
Re: Some Observations on the D Development Process
On 1/5/18 5:08 AM, John Colvin wrote: On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote: I can't agree with the "just close older bugs and PRs." There's good stuff in them. Even if the PR is no good, it provides insight to someone working on a better fix. Closing it means nobody will ever be aware of it or look at it again. Relying on the original author to revive it will not work. It's similar with older bugs. They still have discussion on them that contributes valuable information and insight to anyone wishing to work on it. Closing them with no action means the information is all lost. As for autotester resources, it should be easy enough to have it skip testing any PRs that have had no activity for XXX days. I don't believe "Logan's Run" makes a good foundation for a functioning QA system. +1 A perfect project would be able to make quick decisions on PRs, but that doesn't mean closing PRs makes a better project. It's a little bit cargo-culty. Does anyone know how the statuses RESOLVED/LATER and RESOLVED/REMIND are usually employed? Thanks! -- Andrei
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote: I can't agree with the "just close older bugs and PRs." There's good stuff in them. Even if the PR is no good, it provides insight to someone working on a better fix. Closing it means nobody will ever be aware of it or look at it again. Relying on the original author to revive it will not work. It's similar with older bugs. They still have discussion on them that contributes valuable information and insight to anyone wishing to work on it. Closing them with no action means the information is all lost. As for autotester resources, it should be easy enough to have it skip testing any PRs that have had no activity for XXX days. I don't believe "Logan's Run" makes a good foundation for a functioning QA system. +1 A perfect project would be able to make quick decisions on PRs, but that doesn't mean closing PRs makes a better project. It's a little bit cargo-culty.
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: Another issue is I've had the flu for a while which makes me tired, and then it's best to work on things that don't require much mental energy. I quess that applies easily twice as strongly if you code bigger things on the run, no? :D
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: On 1/4/2018 2:34 AM, Mike Franklin wrote: Walter seems to pop in daily, and occasionally reviews PRs, and his PRs of late are mostly just refactorings rather than fixing difficult bugs. There's a lot of technical debt I've been trying to fix with that, and nobody else seems willing to do it. For example, fixing the error messages so they make use of color syntax highlighting. It's boring, tedious, unfun work, meaning I get to do it :-) Another issue is I've had the flu for a while which makes me tired, and then it's best to work on things that don't require much mental energy. (Yes, I got the flu shot, and the durned thing did not work.) the flu is nothing to sneeze at, at your age.. or mine for that matter ;-( take it easy and recover!
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 04:14:57 UTC, Steven Schveighoffer wrote: On 1/4/18 10:28 PM, Walter Bright wrote: (Yes, I got the flu shot, and the durned thing did not work.) I had a flu shot once in my adult life. Never been sicker. Won't ever get it again. The only people I ever saw with a flu (I mean a real influenza) had all one thing in common: they all had gotten the flu shot.
Re: Some Observations on the D Development Process
On 1/4/2018 9:44 AM, Jack Stouffer wrote: DMD also has at least 30 PRs which have had no action from the author in over a year. There's no reason these should be kept open; they just take up auto-tester resources and lower the signal to noise ratio. If the author comes back later, they can always ask a maintainer to reopen. I can't agree with the "just close older bugs and PRs." There's good stuff in them. Even if the PR is no good, it provides insight to someone working on a better fix. Closing it means nobody will ever be aware of it or look at it again. Relying on the original author to revive it will not work. It's similar with older bugs. They still have discussion on them that contributes valuable information and insight to anyone wishing to work on it. Closing them with no action means the information is all lost. As for autotester resources, it should be easy enough to have it skip testing any PRs that have had no activity for XXX days. I don't believe "Logan's Run" makes a good foundation for a functioning QA system.
Re: Some Observations on the D Development Process
On 1/4/2018 7:41 PM, Mike Franklin wrote:
If you have simple, mundane work that needs to be done, make a list and send it
my way; you should have my e-mail address. But please be specific; "fix error
messages" is just going to get a reply from me asking questions.
Ok, fix error messages, like you've seen me doing already. To find which files
need work,
grep "error(" *.d
does the trick, turning up:
ctfeexpr.d
dimport.d
dinterpret.d
dscope.d
e2ir.d
expression.d
expressionsem.d
func.d
glue.d
iasm.d
mtype.d
nogc.d
nspace.d
opover.d
optimize.d
s2ir.d
as needing ` `. There's a lot of work just there :-( It's best to resist the
urge to do more than just add in ` ` where they are obviously appropriate. Don't
make perfection the enemy of better. I've found it best to have only one PR for
this at a time, otherwise it's a lot of extra work rebasing.
A longer term goal is to find ways to refactor the code to make maximum use of
pure, const, scope, and nothrow.
I appreciate any and all help with this.
Re: Some Observations on the D Development Process
On 1/4/18 10:28 PM, Walter Bright wrote: (Yes, I got the flu shot, and the durned thing did not work.) I had a flu shot once in my adult life. Never been sicker. Won't ever get it again. -Steve
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: There's a lot of technical debt I've been trying to fix with that, and nobody else seems willing to do it. For example, fixing the error messages so they make use of color syntax highlighting. It's boring, tedious, unfun work, meaning I get to do it :-) If you have simple, mundane work that needs to be done, make a list and send it my way; you should have my e-mail address. But please be specific; "fix error messages" is just going to get a reply from me asking questions. Mike
Re: Some Observations on the D Development Process
On 1/4/2018 2:34 AM, Mike Franklin wrote: Walter seems to pop in daily, and occasionally reviews PRs, and his PRs of late are mostly just refactorings rather than fixing difficult bugs. There's a lot of technical debt I've been trying to fix with that, and nobody else seems willing to do it. For example, fixing the error messages so they make use of color syntax highlighting. It's boring, tedious, unfun work, meaning I get to do it :-) Another issue is I've had the flu for a while which makes me tired, and then it's best to work on things that don't require much mental energy. (Yes, I got the flu shot, and the durned thing did not work.)
Re: Some Observations on the D Development Process
On Thu, Jan 04, 2018 at 06:50:25PM +, Dmitry Olshansky via Digitalmars-d wrote: > On Thursday, 4 January 2018 at 18:09:32 UTC, Seb wrote: [...] > > BTW: For those who haven't seen this, dlang-bot now detects these > > stalled PRs and for now labels them as "stalled": > > > > https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/cron.d#L60 > > > > I'm not sure whether auto-closing them is a good idea, but we > > definitely need to do sth. about them. > > Also one year without any activity is a very long time. > > It’s not like we loose anything, we don’t delete code of the author. > So should he/she find time - just create a new PR. Also these willing > to dig in the closed PRs are free to do so (it’s just a couple of > passes to add a filter to your search). I used to think that it's OK to leave old PRs there, since they don't actively cause harm. But lately I'm changing my stance. Having a PR queue that's overly long conveys the wrong image to a potential contributor. Having PRs that are years old with no resolution is discouraging to look at, and also a source of frustration to the submitter, esp. when the change is not especially complicated. So nowadays I'm inclined to suggest that if a PR hasn't had any response from the submitter for, say, 2-3 months, it should be closed with a comment to resubmit if the submitter still feels strongly about it. Note that I'm measuring this by activity *from the submitter*; I don't think it's a good idea to close a PR if the submitter is waiting for somebody from the team to respond. That would send the completely wrong message. So I'd suggest that if a PR has had no activity from the submitter for, say, 2 weeks, then send a ping. At the 1 month mark, send another ping. At the 2 month mark, close it with a note to reopen if the submitter later decides to work on it again. If a PR has had no activity from the team for 1 week, then the onus is upon us to do something about it. I'm not sure what to do when the reason is that none of the active team members feel qualified to handle the proposed change. For example, if the PR touches some numerical algorithms, I would hesitate to review it, because of lack of expertise in the area. I guess this is where the lack of consistent talent is a big liability: if the go-to person for a particular area isn't active, or only rarely active, or just too busy, then there's really not much we can reasonably do about it. Perhaps one small thing that might help is to acknowledge the PR, or take initiative to actively ping the go-to person until he responds. At the very least, this would send the right message that the team cares about the contribution, but just doesn't have the resources right now to deal with it yet. Alternatively, and this is just a wild idea off the top of my head, if the go-to person doesn't respond by X days (where X is some fixed number we agree on), a non-expert team member can do a code-level review (i.e., check for obvious glaring problems, check for basic code sanity) and then merge the PR. Worse comes to worst, the revert button's always there. This has to be done with care, though. Definitely should not be done prior to an imminent release, so that we don't introduce problems that are hard to fix later; but perhaps early in the release cycle it might be OK, under the assumption that any obvious problem would manifest itself sometime before the next release, and the PR can be reverted if necessary. But even then, we might need to mark certain types of changes as off-limits, e.g., if they would be too disruptive, or fundamentally changes the way things work with unknown consequences. Ultimately, though, this is just a crutch in the face of lack of the right talents to do a proper review. Anyway, this is just a rough idea that may hopefully lead to a better one. T -- "Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra
Re: Some Observations on the D Development Process
On Thursday, 4 January 2018 at 18:09:32 UTC, Seb wrote: On Thursday, 4 January 2018 at 17:44:58 UTC, Jack Stouffer wrote: DMD also has at least 30 PRs which have had no action from the author in over a year. There's no reason these should be kept open; they just take up auto-tester resources and lower the signal to noise ratio. FYI: stalled PRs don't take up resources (except they target stable, which is why one of the reasons stable PRs should be merged ASAP). It's due to the auto-tester sorting PRs by their activity. They waste resources of folks looking to review stuff that is actual and active. BTW: For those who haven't seen this, dlang-bot now detects these stalled PRs and for now labels them as "stalled": https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/cron.d#L60 I'm not sure whether auto-closing them is a good idea, but we definitely need to do sth. about them. Also one year without any activity is a very long time. It’s not like we loose anything, we don’t delete code of the author. So should he/she find time - just create a new PR. Also these willing to dig in the closed PRs are free to do so (it’s just a couple of passes to add a filter to your search). Personally, I’d say 3 of months of silence usually enough to put off most except for seasoned contributors. Many opensource projects do even worse job but we should look at the best examples. Dlang-bot currently uses 90 days though imho that's already very conservative. Just tagging doesn’t really help, I already can sort by activity. Example: https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+label%3Astalled
Re: Some Observations on the D Development Process
On Thursday, 4 January 2018 at 17:44:58 UTC, Jack Stouffer wrote: DMD also has at least 30 PRs which have had no action from the author in over a year. There's no reason these should be kept open; they just take up auto-tester resources and lower the signal to noise ratio. FYI: stalled PRs don't take up resources (except they target stable, which is why one of the reasons stable PRs should be merged ASAP). It's due to the auto-tester sorting PRs by their activity. BTW: For those who haven't seen this, dlang-bot now detects these stalled PRs and for now labels them as "stalled": https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/cron.d#L60 I'm not sure whether auto-closing them is a good idea, but we definitely need to do sth. about them. Also one year without any activity is a very long time. Dlang-bot currently uses 90 days though imho that's already very conservative. Example: https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+label%3Astalled
Re: Some Observations on the D Development Process
On Thursday, 4 January 2018 at 10:34:05 UTC, Mike Franklin wrote: A few of us are working hard to revive old PRs and either see them across the finish line, or give them a quick path to closure. 2 months ago the DMD PR queue stood at about 190. Now it's hovering between 140 and 150. DMD also has at least 30 PRs which have had no action from the author in over a year. There's no reason these should be kept open; they just take up auto-tester resources and lower the signal to noise ratio. If the author comes back later, they can always ask a maintainer to reopen.
Re: Some Observations on the D Development Process
On Thu, 04 Jan 2018 10:34:05 +, Mike Franklin wrote: > This is in response to some of the frustrations offered in the thread > staring with > http://forum.dlang.org/post/oeigdutfphxhenexc...@forum.dlang.org > > I share some of those frustrations, and I've been vocal about such > things myself. However, in the last 2 months, at least in terms of the > DMD repository, things may be starting to change for the better. > > Recent Promising Progress - > A few of us are working hard to revive old PRs ... This is an important post. It's easy to make a habit of complaining about things, but it's good to stop and say "but look where we are right now." You do this without acting like all problems are being solved, too. So thank you. I do think it's important to mention that the improvements you've mentioned came about because some people said "we're going to fix this" rather than wait for someone else to do it. There are problems that can only be resolved by one or two people, but there are many others that anybody take can take care of.
Some Observations on the D Development Process
This is in response to some of the frustrations offered in the thread staring with http://forum.dlang.org/post/oeigdutfphxhenexc...@forum.dlang.org I share some of those frustrations, and I've been vocal about such things myself. However, in the last 2 months, at least in terms of the DMD repository, things may be starting to change for the better. Recent Promising Progress - A few of us are working hard to revive old PRs and either see them across the finish line, or give them a quick path to closure. 2 months ago the DMD PR queue stood at about 190. Now it's hovering between 140 and 150. So, we're getting better; take a look at the graphs here for evidence: https://auto-tester.puremagic.com/chart.ghtml?projectid=1. Notice the spike in PR submissions in December, and we're still 40 PRs less than we were 2 months ago. 2 months ago, the oldest PR was dated 2012, believe it or not: https://github.com/dlang/dmd/pull/1145. Our oldest is now 2013, which is still pretty bad, but it was partially revived recently at https://github.com/dlang/dmd/pull/7503. Unfortunately, it's probably the most difficult PR we have. I'll take the risk of arguing that we've widened the review bottleneck recently for straight-forward PRs. However, for difficult, complex, or controversial PRs, it still looks like we lack contributors with the right skills that are willing volunteer their time, and tolerate some inconveniences. There has also been a lot of work done on improving infrastructure for testing (e.g. Adding the Appveyor CI for testing Windows) and automating some of the mundane tasks (e.g. https://github.com/dlang/dmd/pull/7507). A Few Observations About Our Talent --- IMO, one of the most worrisome issues we have is a talent retention problem (at least for DMD). It appears many of those with the talent to review and fix difficult compiler bugs are no longer active, or just pop in from time-to-time. I'm not sure why that is. I know a few have left or don't participate much due to dissatisfaction in the way D is managed. Others, I think, were working on D as students and now have blossoming careers outside of D to maintain. I also know of at least one that found Rust to be a better alternative. But, I can also understand how someone would just grow sick and tired of working on the same thing for months or years. Walter seems to pop in daily, and occasionally reviews PRs, and his PRs of late are mostly just refactorings rather than fixing difficult bugs. We desperately need his help on the more difficult issues (e.g. https://github.com/dlang/dmd/pull/7568 and https://github.com/dlang/dmd/pull/7566), but I don't know if he's well-aware of those items and just busy with other things, or if those items are simply not on his radar. If it's the latter, and it would help, I'll publish a digest periodically. Andrei pops in unpredictably, and sometimes goes on a PR review rampage. The infrequency, however, makes it difficult to follow-up and maintain momentum on individual items that need his judgement (e.g. https://github.com/dlang/dmd/pull/7099) That being said, there are some very talented software engineers active on this forum that are only seldom active in the PR queue. I don't know why that is; perhaps it's simply a matter of time and energy, or perhaps it's frustration. As others have said, you don't need to have commit access to be a helpful reviewer. And, after showing a willingness to participate, demonstrating your abilities, and earning the confidence of the leadership, you might be asked to join the team, and then you'll really be able to make things happen. Final Words --- Due to recent changes, if you have a straight-forward, non-controversial PR, it will likely be merged in a week or two; usually less, and sometimes even within a few hours. If the PR is difficult, complex, or controversial, then it may languish in PR purgatory for some time, unfortunately. I don't know what can be done about that at this time without skilled, frequently-active talent. My two-cents, Mike
