On Tue, Feb 21, 2017 at 02:59:27AM +0000, Skip Tavakkolian wrote: > > It begs the question of how do we organize a community maintained > repository?
There isn't "a" community, so it's pretty pointless. The list you posted is the complete list of stuff that matters with the possible exception of Forsyth's 9k repository [1], which doesn't appear to have got much updating recently. The point is, there's not that much to keep track of, and anyone who cares will not have a terrible time keeping up. The only time this has failed me was when a 9legacy patch written specifically for Go took us by surprise (we got users mentioning a release candidate wouldn't build). I whined on Go's issue tracker and they promised to mention such breaking changes in the release notes.[2] In short, the people who give a shit about revision control are already using it, the SP9SSS isn't going to start using it in public, and trying to get everyone under one tent isn't going to work because git hipsters literally suffer from organ failure when you ask them to try mercurial, even though there isn't a (public) git port for Plan 9. What it boils down to is two classes of makework: watch the commit logs for 9k[1] and 9front[3], and write a script that automates pulling 9legacy's patch list or 9atom's image and diffing them for you. Both 9k and 9front have facilities for having commit logs mailed to you, if you'd prefer. They both also support rss/atom feeds. khm [1] https://bitbucket.org/forsyth/plan9-9k [2] Instead we got instructions to read the Go wiki, which documents required Plan 9 changes and when some were put in, but not which particular Bavarian fire drill affects which particular release of Go. But this is a Go problem, not a failure of the Plan 9 world. And the wiki is better than nothing. [3] http://code.9front.org/hg/plan9front/
