If you're noisy, you can count on me to lose at home.

Status:

Recently the project is too busy, so the update is not much, but please rest assured that will not abandon the pit, but also concerned about not pregnant, let alone pay attention to this public number of male and female ratio 98:2.
All the code to understand the project on-line pain, before the line, the code like their own son, how to see is so perfect. A line, on the people set collapse, constantly in the heart of the dark scold "what TMD thought." Are you able to smell the bugs across the screen when you've been living in this state lately?

Image

The upcoming go 1.11 will include support for Go mod, which solves the long-running, management-dependent short board of Go. But this article is not about the Go module itself, but about the conflict between the go team and the community--you can see the style of Go teams and the simple gossip.

Let's talk about the background. Go as a project within the Google incubation, the design of the pair is very consistent with Google's internal use of the scene: all the source code is in a huge repo, relying on the VCs inside the path, the construction of all from the latest source code compiled, and ultimately only a single executable file output. But not all companies that use go,google like Google need better dependency management, mainly:

1. Dependent version control to produce stable and predictable build results without the influence of dependent module code modifications

2. Stable dependency path to be compatible after project VCs address changes or fork VCS

As early as http://gopkg.in/such a scheme, through a jump point to the real VCs address, the URL of the different versions jump to different branches. Later, with a variety of third-party dependency management tools, after the vendor mechanism emerges, these tools are implemented to solidify the dependency on the vendor. After that, community members set up committees and working groups for package management tools with the approval of the Go team, and the organization developed DEP as--or they thought--as the official dependency management implementation.

However, by the year 18, Russ Cox has also developed VGO's experimental project, which has led to confusion, and go has two official dependency management tools? What is the relationship between VGo and DEP? As VGo finally standardizes and goes into go 1.11, called Go module implementations, the dust settles, and DEP's so-called official is just wishful thinking for community developers, with only a vgo of red shoots.

This is how the story begins.

VGo into Go 1.11,russ Cox sends a Twitter:

Img

Russ Cox: I am very excited about how go module is implemented in Go 1.11. Last time I looked at the most popular about 1000 items, 93% of them can be converted directly to go Module.

After Twitter came out, Sam Boyer (the main developer of DEP), turned one (not the original in English, and can go to the link at the back of the article):

Sam Boyer: The initial (old project to go module) conversion is never a problem, and the problem is stealing work from unpaid contributors.

My GOSF speech last week was about this. The video can't be found now, but I've cut a picture.

Russ Cox replied to this push:

Russ Cox: I listened to your speech. Although we have been talking for a long time, it is clear that you are frustrated with all of this now, and I am still feeling discouraged. I'm really sorry about that, I know how it feels.

Sam Boyer: I appreciate it if you can say that. You must also be very difficult, I am also sorry for the excessive pressure caused by this matter.

But this is not between you and me, I mentioned you in the speech because you are the source of the later community culture and mechanism controversy.

Another important contributor to the go community, Peter Bourgon says:

Peter Bourgon: Because I know some people in the event privately, I admit that I am biased. But as an outsider saw the scene of the accident, I might have a little more interest in rust later. Why does the Go team leadership always refuse to learn from other modern languages?

Russ Cox:go is not about meeting all the needs of everyone. If you like Rust's way, go with rust. I also admire rust, and in fact I spend a lot of time studying the good places in Rust,swift, but the one that fits a language may not be suitable for other languages.

Peter Bourgon: Yes. But I can't think of a reason why the dependency management of go does not learn anything from other dependency management. From an outsider's point of view, the go hysteria attempt does not reach any consensus that anyone else has reached, and I don't understand why.

And it's not just your problem. I was involved in the discussion before DEP started, and I've been focusing on glide before. I don't know why the dependency management community of Go is not learning from other issues that have already been encountered (package management).

As an already proven language and community in providing out-of-the-box tools, I am very confused about why such a critical part of the package management is almost deliberately designed to be so lame.

Well, Peter Bourgon is actually a bit crooked.

Russ Cox: We are a small team, and there are other priorities to be done. It is true that we are a few years late in this field, but things are going on in the right direction, and in a few years we will see what we are doing.

Matt Farina (glide author) jumps out.

You say you are a small team because you think of go as a product of Google's team, the Google team is small. If you create a community, with the power of others, it's a big team. Rust's dependency management team, for example, has people who are not Mozilla.

Under siege Russ Cox opened the crazy push mode, bursts n Twitter to explain the causes and consequences.

Russ Cox:

Very reasonable criticism. We are not dealing with community processes that depend on management. Go's core team did not have this morning and enough to participate in the process, not being able to guide the smooth landing. As a technical head of go, it's my responsibility, and I apologize for that.

Since the start of writing "Go get", the go core team wants the community to take over management-dependent matters. Keith Rarick's Goven, then GODEP, and Matt Butcher's glide, has been Dave Cheney's GB, and is one step in the final solution.

In the spring of 2015, Jason Buberel investigated these programs in an attempt to find ways to unify the various programmes. The information he collects shows that the main issues of these programs lack support in the Go tool chain, which is our current vendor mechanism.

Jason's collection of evidence allows me and Rob Pike to believe that we need to increase the vendor mechanism, which we have added as an experimental feature in 1.5 and officially released in 1.6.

Daniel Theophanes led the preparation of the Vendor.json format standard so that different dependency management tools can interact with each other. I wrote vendor as a community success story in Go blog. But we don't have a unified language to describe go dependencies.

In the summer of 2016, there was a discussion of Go pack management on Gophercon, which eventually created the Working Group and the Advisory Board. I was taking paternity leave, and Andrew Gerrand on behalf of the GO team.

By November, Andrew was going to do something else, and I started to get involved. As soon as the Working Group started to develop a single tool that could be used, I wanted to make sure that the overall design was finally well integrated into the GO command.

In December 2016, I started writing e-mails to Sam to discuss design. I want to use versioning as part of the go build so that users don't need additional processes. I asked him if it was too expensive. I also wrote a version of the SAT question article.

We also discussed the conflicts that were caused by relying on multiple versions of the same package, and Sam highly evaluated the practices in cargo (Rust's pack management tool).

We also discussed the need for go compile and build support for integration with the Go tool chain, including changing the semantics of Gopath and vendor.

I said that while the final integration into go will be different from what is now, DEP still needs to continue to develop and provide more experience. Sam seems to agree.

In January 2017, when Dep was released, the name changed to hoard, and in the discussion I mentioned again that DEP would not simply be integrated into go dep or go hoard.

In March 2017, Sam sent an e-mail to the Golang-nuts Mail group with a link to merging into Go toolchain. The roadmap seems to be to put DEP directly in the Go software package.

In my reply, I reiterated the need for changes to integrate DEP into go toolchain, as well as the concern that Sam would use DEP as a more official solution to the role it was supposed to be.

Sam used the word "official experiment" in his reply, and I still think it's a good word right now. A experiment is used to validate a hypothesis and gain more knowledge about something.

In June 2017, I shared a document with the package management team about the idea of integrating the Go tool. Sam and others helped me discover some of these flaws. I'm going to post it here now.

A few days later I met with the team to discuss the design. Because Andrew was absent, I took notes to him. I'm going to post it here now.

We discussed DEP in Gophercon Contributor summit. Matt Farina said I said that if I could do better myself, I'd make sure I didn't (say that). The impression I'm talking about is that DEP needs to be modified to be integrated into the GO command.

One topic of discussion is about the future of Dep. I once again stress (the package Management work group) process is to better understand the problems we are facing and ultimately to provide smooth integration in the GO command.

I realized that the integration into the GO command required considerable effort to modify something inside the Go command, and I spent some time in the mid 2017 to implement the build cache, which was released in go1.10. The build cache makes gopath/pkg obsolete and does not require this in versioned dependencies.

After Gophercon I took a vacation and then went to another project to help, and then came back to finish the build cache. After the build cache can be used, I can verify multiple versions of dependency issues. It was now November 2017.

Later in November, I sent a draft to the working Group and met them to understand their ideas. I haven't written the code yet, and I'm still trying to figure out what to do with go integration.

Draft end recommended DEP supports semantic import versioning. Sam and Peter argue that the changes are too late, DEP does not change, and should be integrated into go dep.

I would like to publish a draft of import versioning for public discussion. Sam let me wait, don't spoil his holiday. I agree with you. Starting in December, Sam and I met two times a week to discuss the problem of go integration.

Since DEP is reluctant to support import versioning, I have directly modified the GO command to verify the idea. I found the best combination of import versioning and minimal version selection, and implemented it.

At the beginning of January 2018, I had a design that I wanted to discuss openly, but there was no good or bad implementation to verify. But Sam had a speech on DEP February 3 in Fosdem and I didn't want to complicate things, so Sam and I continued to communicate but didn't publish.

In mid-February I finished my work demo, and I was sure there was no big problem with the design. Sam's Fosdem speech was over, so I released my design and prototype implementation. It's fried.

We all know the rest of the matter. After several months of design revision, it became a formal proposal, accepted, then implemented, then merge into the trunk, preview in 1.11.

The initial go get has been 10 years, and we've replaced it. Our goal is to create a tool that will continue to serve ten years for go users, especially when the size of the code and the development team are getting bigger.

DEP is a successful experiment. It validates the "tag versions, record Boolean constraints, solve with SAT" method used in bundler and cargo, and I also learned a lot from DEP:

(There are a lot of things learned from DEP, omitted here, interested to see the original text on Twitter)

Why does the Go team say go supports version (referring to sementic import versionging)? First, we created go, and I designed the GO command. The most important thing we want to ensure is a consistent vision that makes go go. Part of the vision is making it easier to develop large-scale software, including Internet-scale open source projects. While it's too early to say what's best, we can learn from other systems why they don't scale and avoid it.

Whether big or small, we have a process to modify go: mention proposal. The Go core team helps support important points to match the go design and vision. We guide community discussions to reach agreement.

Not every time the community can agree, the Go core team makes the decision. In principle I am the final determinant, and actually the go team has the time to discuss internal agreement.

And DEP has never been a proposal. The Go Module proposal is widely welcomed by the community, although Sam and a handful of others are not. I left the right of decision to other proposal reviewer, who considered the problem and eventually accepted my proposal (well, who dares not to accept it).

The Go module was not designed to be perfect, but he solved the problem and laid a good foundation for the next era. We are very willing to improve it with anyone who is willing to help us.

Looking back, as I said at the outset, our go team failed to take care of the community process and I apologize for it. We should continuously participate and revise the route to be able to integrate into the Go tool chain.

In any case, I do admire the community involvement of the Rust team. In order to be successful, they understand the key points and devote themselves fully to the community contributors. And in this process, I didn't do it for too long.

It's unacceptable for us to give up DEP and make go module look like a huge route fix. The whole community was shocked to know the results, because we had only communicated to the people who managed the work group in the package.

I thought I just had to focus on the technical details and let the team's people and the community communicate, and the result was that the entire community felt that DEP was the official implementation, although it was clearly stated in my communication with the Working Group.

In retrospect, the biggest mistake I made was that there was no broader and more open discussion of DEP, and I wanted the working group to speak with a voice.

It seems like I'm just talking to Sam and the rest of the team about what you need to do to integrate DEP and DEP into go, but these are ignored by Sam, and the result is that DEP can't be integrated into go as a fit implementation.

In various ways, DEP appears in the name of the final package management program, even though we told Sam Dep in December 2016 that it was only a step in the process and would eventually be replaced.

If the discussion is open, everyone's expectations may be different. It might also make it easier for DEP to absorb and integrate the design.

Again, I apologize for all the mistakes I made during this period. I learned a lot from what successful community partnerships need to do and don't need to do. Hopefully the next process will work better.

Too long, a simple summary: I have a management responsibility, I apologize. DEP is not an official implementation at first, it's an experiment and you think much. I want sementic import VERSIONING,DEP not supported, so I can't integrate DEP into go. Now I've got the Go module proposal and the prototype implementation (VGO), everyone said.

The following onlookers eat melon people have said you do not need to apologize, you do a good job, the project is much worse than this.

Matt Farina A few more Twitter responses:

First of all, thank you for sharing so many ideas openly.

I think you didn't catch me a very important point. In Gophercon's package management workgroup meeting You said there were too many DEP lines and the go team couldn't maintain it. This shows a problem that the go problem is ultimately decided by the Go team, and no one else has the right to speak. All you say in your reply is the work you do, whether it's past or recent. The focus is on your work with the Go team. Mentor-Apprentice relationship how to become a community-led, how to consider community views?

Is the community a part of the dominant person or a mere product user? Why can't a dependent management be an independent team? A team that is experienced and focused on this issue. Tools and complexity are expanding, why can't you hand over a part of the dominance to the community? That's what other languages do.

There are vgo, or go module has all kinds of problems, some of which you have admitted to me. The solution you quickly conceived makes things more complicated and opaque to go users.

Both VGo and DEP have their own problems. VGo I talked to some of the people you recognized, and they were concerned about it. These concerns are mainly in the style.

There are two main problems with go:

\1. Go is a Google-provided product that others can use, but without a voice. Small, highly-controlled teams and communities are separated, and grudges are getting bigger.

\2. A new dependency management model (presumably worth the import versioning), with unfamiliar and unverified issues

Peter Bourgon the "A response about DEP and vgo" response on his own blog post. Just pick the key parts.

Russ Cox, Twitter, describes Dep/vgo's story from his perspective. It is not pleasant to argue about history, but there are some subtle and important things in the narrative that are important to me because I have experienced these things and my memory is inconsistent with these narratives. I think it's important because the go team spends a lot of time and energy promoting community culture, and I think the incident, though a bit messy and complicated, is a perfect proof that they haven't figured out the right way. It is important to have a precise history so that you can avoid similar problems in the future.

Russ started with some history, I jumped straight to the point where there was a debate.

(citing July 2017 of its sharing of design documents to the Working Group and Twitter discussed on Gophercon)

I was also present at contributor Summit, who presided over several meetings of the package Management Working Group. I don't remember Russ precise words, but I remember the final result. When the conference process was halfway through, Russ, who said he now understood that he needed to solve the problem himself, might have just started or half-finished, and he wanted to give some feedback.

The obvious impression is that Russ does not intend--at least not yet--to participate in the Committee, including the research we have provided to him, and the prototype of the study to achieve DEP. Russ has his own theory about the final plan, and he would like to test the theory himself. It was a meaningful communication at the First Committee and Russ, and we were excited to finally get the attention of the core team, cautiously optimistic, and the result was the beginning of the bad news.

Matt writes:

"I saw Jess, and Sam and the others uttered a sigh and bowed their heads. It looked as if the air had been drained from the room. I am so depressed that I tell you directly that this is not the right way to treat the people who put the time and effort into this thing. "

I also remember this moment clearly, as Matt wrote.

(citing November 2017 draft proposed DEP support Semantic import versioning Twitter)

This is absolutely not true: no one in the committee wants to make DEP simple as go dep. We are proposing to add some sub-commands to the integration as a first draft to keep the discussion going, but we never insisted on adding a sub-command like ensure to the final product, from day one everyone was aware of it.

Indeed, we know from the beginning that deep integration into go is necessary. We also know that we need to ask the author of the Go Command-russ's consent to come up with proposal, so we cautiously deferred the decision to Russ after the meeting. In fact, we avoid making decisions in what we consider to be the Go tool area to make future integration easier. DEP puts forward a lot of drafts, such as ensure, to work in the absence of Russ to continue.

At the time about semantic import versioning we had several discussions, Russ was not able to persuade the Committee it was necessary, and we did not agree to revise DEP to support it. Maybe that's what he remembers.

(The article is very long in the middle about the details of the tear force jump past.) Want to see the original text it)

(citing an unacceptable Twitter waiver of DEP)

It is dishonest to say so. The correction of the route also shocked all the package management team members, because until VGo's article came out, each of us still had the hope and expectation that the core team would continue to work with us in order to get DEP to an acceptable state instead of proposing a whole new thing.

We deliberately avoid proposing a proposal before establishing a more formal communication channel with the core team. Much of the development work of DEP (and the core team) is not communicated at all. We--at least myself--after the advent of VGo's article, I still hope that the technical conflict between Russ and Sam will be resolved and that a DEP proposal be proposed. Remember: At that point, Russ only two or three times out of our meeting, and this meeting has been going on for two years now.

Russ's technical claims are certainly not overlooked, and we have widely debated these propositions. They just didn't convince Sam and the Committee. Rather than optimizing those propositions to make them more persuasive, or to find a compromise with the Committee, Russ decided to implement his own ideas, put aside our own proposal, and not tell us until we were done. It must be said: As Go's technical leader, Russ certainly has the right to do all these things. But what does such a project reflect?

(Omit another paragraph here.) )

When the DEP committee was set up, I did everything I could to make it and the work it was doing, as reliable and invulnerable as possible to protect the credit of the Working Group, the reputation of the team members, and the effectiveness of the products produced. To replace the guidance from the core team, and even the basic communication, we decided to:

-Recruit members from community leaders and experts

-Set up a sub-advisory group to support all relevant projects

-spent half a year collecting user feedback and conducting research in the field

-Detailed review of all other meaningful package management tools

-Unison design, objectives agreed on all major decisions

-All of it, all painstakingly, publicly documented documents

We do all of this because we want to be a community that can be a step closer to solving the problems that have been overlooked by the core team. I can't find anything better than what we've done. But as a result, these efforts are as we have never done anything: The core team ultimately does not participate in the results we contribute, but insists on doing it ourselves, essentially a completely new project that starts from scratch.

I think the end of Dep/vgo is a good illustration, though the go leadership is happy to accept contributions to issue and uncontested proposal, but still struggles with the contributors to large-scale autonomous self-government. Right in Google's core development team.

If one day I make a speech about this final failed project, I'm going to put a slide at the end, with a picture on it, a boat wrecked on the island, and the captain said, "The point of your life is to warn other people." I hope this story gives someone a warning: "If you are interested in making a substantial contribution to go, independent hard work cannot compensate you for the design that is not from the core team."

Perhaps some readers read this and say, "Perter, isn't that obvious?" Maybe it is. (I didn't realize it was) my fault.

Addendum (the author read the discussion on Reddit added):

The discussion that sparked me inspired me. I think I have a better perspective on what's going on. I think the DEP team and the core team each had a completely different understanding of the conversation until the VGo article appeared to collapse the quantum state.

The DEP team believes that DEP is not the same as the tools that appeared before, and is a community-driven final go-dependent management solution that has been researched and carefully considered. The core team believes that DEP and the previous tools are essentially the same class and are part of the prelude to the final program they designed.

I believe that the DEP team is well aware of their position and what it is like to be able to see it in the presentation of the core team. But obviously (the DEP team member) did not generally understand the status until it was too late, until it was too iate. Alas, it was obvious after the fact, but who was able to see it?

Image