From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> To: 9fans@9fans.net Date: Sat, 26 Jun 2010 11:26:21 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3731dd1c-ead6-11e9-9d60-3106f5b1d025 > but I can dig > them up, clean them up, and share them, My particular concern is to encourage convergence towards a single source distribution rather than divergence as seems to have been the case so far with Plan 9 native, Inferno, p9p and now Go. What I have chosen to do, ill-advised as it may be, is to set up a mercurial repository to re-distribute hacked Go sources that mostly contain harmless changes that make it possible to compile the Go sources and specifically the development toolchain with the Plan 9 toolchain. I'm presently trying to bring the work I did last year into this repository and at the same time keep track of the Go release. I'm hoping that others will also find this repository useful or, even better, make reasonable suggestions on how to improve it to achieve objectives of benefit to the Plan 9 community. Mercurial is great this way because one can stream changesets back into the release repository when they are ready, but allows different groups to work on possibly conflicting projects and worry about merging much later. Anyway, if anyone wants to access the repository, I will gladly grant him or her access. At the same time, my recommendation is that as much as possible, changes should be submitted through codereview (see the Go documentation for details, Russ has done a very good job of explaining things there) rather than as alternative development streams. But some changes are worth having before they mature, a public repository is a good place to dump such changes and let others try them out or comment on them. As I think about it, it seems strange that I should be duplicating codereview, but I think Plan 9's more aggressive approach to filtering changes was influential in my thinking, my subconscious assumption is that most changes need multiple iterations _before_ submitting, but this assumes that reviewers are an expensive commodity as is the case at Bell Labs. I don't know if the Go Author are operating under the same conditions. And, obvious sequitur, what would it take to replace Plan 9's "patch" approach with a "codereview" one? It seems to me that everyone might benefit from it. ++L