Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
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.
Reply to: