On 06/27/2016 01:10 PM, Walter Bright via dmd-internals wrote: > Of course you have a great point. The trouble is, for me anyway, it's > hard to write the spec incrementally. It also tends to make for a crummy > spec. I find it easier and works better to take a more holistic view of > spec updates. > > For example, I am currently working on the list of issues tagged with > 'safe'. Many of them interact with each other. It's easier to work on > them more or less in parallel when I have the 'context' of how that part > of the code works in my head. The same goes for spec updates. > > But I don't want it overlooked, hence the shortcomings should all have > bugzilla entries.
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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
