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