Remember that flavors and multi-packages should not be used to group together independent stuff.
I did that mistake in the past, for instance in kde/i18n3 (with flavors) and others did similar things with multi-packages for www/firefox-i18n Basically, those kill dpb. dpb considers a set of multi-packages as one single build, and dpb locks a directory when it's building in it, thus preventing other flavors from building (this is necessary because often, flavors come with multi-packages, and some flavors may only affect some of the subpackages, so if we allow several flavors to proceed in parallel, we have races between the same subpackage being built concurrently by different flavors. This is *not* theoretical, we have already run into that race). So, independent builds make for maximal parallelism. Of course, this does not change anything for ports that have a good reason to have flavors, or to be multi-packages. In general, those ports have one single build that leads to multiple results. But grouping independent builds in a single port because it seems logical is a mistake! This also goes for documentation and such: if the documentation is provided as an independent distfile, if you build a separate package for the documentation, and if building the documentation only requires installed tools (not the work directory of the corresponding software), then it should be a completely separate port. Again, this is not theoretical. I've had full dpb builds get starved at the end because they were serializing the vim-spell packages. And I've also seen various dpb partial builds get starved for similar reasons.
