On Wednesday, August 23, 2017 at 3:24:26 AM UTC+1, Linker Lin wrote: > Hi,All! > We must remember the tragedy of python 3.x . We should not separate the > Go into 2 versions. > If we launch Go 2 whatever the situation is, we must drop Go 1 immediately. >
That will not happen. Please read the blog post and watch the talk. It is very clearly stated on how to process will work. > > On Wed, Aug 23, 2017 at 5:12 AM, sfrancia via golang-nuts > <golan...@googlegroups.com> wrote: > > As one of the few people who participates in the proposal review meeting I > thought I'd shed some light on this. > > > Go is intentionally simple. A lot of work has gone into the small balanced > set of features. In fact prior to 1.0 a good number of features were removed > as they weren't needed. > > > The statement "As a community we are used to deny the value of some novel > propositions." is just not true. It's not true about the community as a whole > and it's not true about the project leadership. > > > With each proposed feature we weigh the value of that feature vs the cost of > adding it. We consider many costs including the cost to implement the > feature, but also the cost of complexity, the cost of education and the cost > that comes from transitioning to a new change. In many cases the value > provided simply doesn't outweigh the costs, sometimes it does, but the Go > project leadership never denies the value of any proposition. > > > To make another clarification, in his keynote Russ both announced Go 2 as > well as defining the process by which technical decisions are made for the Go > project. The process outlined is not "the Go 2 process" but rather our > process for developing Go and it applies to all future versions (including Go > 1.10). > > > Now to address some of the feedback in this thread: > > > First, please read and re-read the blog post on this. A lot of time and > thought went into both writing that post as well as the process it conveys. > Many things have been said that show a fundamental lack of understanding of > that post. > > > I want to call out a specific part of this post. While they are called > "experience reports", what we are looking for is more specific than just > experience. > > > > > Step 2 is to identify a problem with Go that might need solving and to > > articulate it, to explain it to others, to write it down. > > > > What is absolutely essential is that there is 1. a written report 2. that > identifies a problem 3. that the author is experiencing 4. with Go. > > > If it doesn't have those 4 components, then it isn't an experience report. > > > Without an experience report accompanying it, a proposal lacks grounding. > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > Regards, > Linker Lin > linker...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
