The DIP Process

Nick Sabalausky (Abscissa) SeeWebsiteToContactMe at semitwist.com
Fri Mar 1 05:24:25 UTC 2019


My take on all this (not that it counts for anything):

See? This is what happens when you introduce bureaucracy/red-tape to 
problems. You get the same problems, just with much slower progress.

Frankly, I think we already have far better mechanisms that anything a 
supposedly-improved DIP process could ever provide: Github reviews and 
CI tests.

Looking at DIP1016 in particular:

1. Using the same Github code review process we already use to get 
things done instead of this "The DIP Process" contrivance would have 
allowed the DIP the flexibility necessary to receive W&A feedback sooner 
AND respond to such feedback without the "Too bad, go back to start, try 
again" formality-for-the-sake-of-formality worthlessness.

2. The test suite is going to do a ****FAAAAARRRR**** better job of 
rooting out technical problems than five years of human-review. Does 
anyone seriously think it *wouldn't* have caught the issues with 1016 
right away? And even if so, does that say more about the DIP process, or 
does it say more about the test suite?


More information about the Digitalmars-d mailing list