From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon,  2 Dec 2013 14:52:21 -0800
From: Anthony Martin <ality@pbrane.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20131202225220.GA11998@dinah>
References: <7ae72d180fdae73e741ff98b0192b583@proxima.alt.za>
	<80bad6333ec4976e8c89570f0918b298@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <80bad6333ec4976e8c89570f0918b298@coraid.com>
Subject: Re: [9fans] Go and 21-bit runes (and a bit of Go status)
Topicbox-Message-UUID: 8ed2fc7a-ead8-11e9-9d60-3106f5b1d025

erik quanstrom <quanstro@labs.coraid.com> once said:
> On Mon Dec  2 10:01:48 EST 2013, lucio@proxima.alt.za wrote:
> > > is the threat standing?  that is, if the plan 9 port is broken again
> > > when 1.5 rolls around in just a few more months, does the plan 9
> > > port get booted then, too?
> >
> > The threat is real: Plan 9 is a burden for the developers and lack of
>
> perhaps we're seperated by a common language.  "standing" in the sense
> that for each new release does the same condition hold: if it does not
> pass all the tests, it is evicted from the main line.

Yes. The relevant statement from the new policy is:

    If a builder fails for more than four weeks or is failing at the time
    of a release freeze, and a new maintainer cannot be found, the port
    will be removed from the tree.

    Due to backwards compatibility concerns, removing a formerly working
    port should be a last resort. Finding a new maintainer is always
    preferable.

As of now, both Aram and I are willing to be active maintainers.
(He's just finishing up the Solaris port).

> > The solution is not with "open source" but with rolling up one's
> > sleeves and figuring out how to converge as much as possible the
>
> given that most of the time is spent bailing water out of the boat,
> and fixing things that weren't previously broken, it seems to me that
> like anything it's a two-way street.
>
> anyway, what's the argument for not just forking?

I think forking would actually *increase* the maintenance burden
for us, assuming we want to keep up with point releases.

We would still have to track the changes from upstream and we'd
no longer even be on the Go team's radar. This would naturally
result in more Unix-based assumptions that we'd have to deal with.

For example, I've seen many examples of code that calls certain
functions in the syscall package and just assumes that, e.g.,
Getrusage is defined everywhere. This is even present in the
new Go Performance Dashboard code (written by the Go team).

  Anthony