I often think about this problem, and I start to wonder if step 0 is to try and enumerate it properly. That is: I picture in my mind some kind of huge diagram (perhaps generated from more structured data, I dunno, something into a graphviz) of a landscape of debian developer tools, grouped by some kind of categorisation that might overlap (venn diagram style), so you'd have dh and cmake in one place, git-buildpackage, dgit, possibly others in another; and also our documentation: not just maint-guide but developers-reference, wiki pages, etc.
Such a thing could potentially be annotated with relevant statistics (number of source packages in archive using dh; cmake; etc.; number with Vcs headers, pointing at git or svn or ... repos;) I'm inspired by the Debian Women wiki's diagrams of packaging workflows which took existing flows and presented them in a way that made them much easier to understand as a whole (and also made it clearer how complex they are, or aren't) Then we could look to see what should be eliminated in order to make the diagram simpler. We could re-calculate/draw the diagram on a regular basis: annually (or even monthly if we had much movement behind this idea of simplifying the landscape) to see what the current state of the art is, and compare it to the case last time. We could even attempt to formulate the 'ideal picture' diagram, as something to work towards, although we would not likely get a complete consensus on any one version of that. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
