On 6/27/2016 5:40 AM, Михаил Страшун via dmd-internals wrote:
There are always ways to address it. For example, creating aggregated spec change PR with checklist referring to dmd/phobos implementation PRs and modifying iteratively. Or preparing big chunk of related changes in separate upstream branch as Daniel has suggested. It is state of mind issue, not a technical one. Once ones mind is set strict to fulfill certain contribution criteria, it won't take a long time to find appropriate pattern to do so. The trick is to suppress inherent programmer laziness and actually start looking for that pattern by straight out declaring compromise/exceptions unacceptable. This is a typical short-term benefit vs long-term benefit choice scenario. Making small compromises to make ones daily work more convenient and productive may seem reasonable but it usually harms product health in the long term, the worse so the more people work on it. I am pretty sure whatever issue or inconveniences you may have, community will be able to suggest workflow of comparable convenience but without as high maintenance risks.
In a way, adding action items to bugzilla is doing the checklist, albeit in a different order. I know I rely heavily on bugzilla, often adding things myself as checklist items.
Also, it's often the case that a design change looks great, but comes unglued when it is tried in implementation. (C++ has been burned a couple times by accepting spec changes that nobody had implemented yet.)
The way C++ progress works is much more process oriented than we are, but they have a lot more people working on it than we do. I think you are quite correct in the value of the process for a larger organization, but we're still a pretty small group of core developers.
Doing things in branches works better for larger organizations. For small ones, like us, doing things in branches means it will get essentially zero testing, because everyone will wait until it is done before even looking at it. We just ran into that issue with the SafeInt thing.
As our organization has grown, we have added process here and there as it became clear it was strongly needed. I'm reluctant to preemptively add process, though, before it is an obvious problem.
tl,dr: Larger organizations need more process, but more process needs a larger organization to support it.
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
