> 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


Reply via email to