On Wed, Jan 04, 2017 at 15:14:12 -0800, Brad Fitzpatrick wrote:
> * (Related to the prior item) Start load balancing the Github & Gerrit
> review load. Currently a few of us have tried to look at everything, and
> obviously that can't scale as Go grows. We need to load balance incoming
> code reviews & bugs for a first-pass review for obvious issues before
> marking them as ready for more thorough reviews. I don't have an exact plan
> yet. I'd like to figure this out with the community. To some extent an
> informal system has evolved (I see many people helping out in Github and
> Gerrit with incoming stuff, thanks!), but our tooling and documentation
> around it all is lacking.
I think a good way to horizontally scale would be to better define what
people take care of what aspects or packages of the Go project. Then it
would be easier to add granularity and make space for more people,
taking some work off long-term contributors.
For example, I know from memory what people do cmd/compile* stuff, but I
don't think that's documented anywhere. A wiki page might be good.
--
Daniel Martí - mv...@mvdan.cc - https://mvdan.cc/
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
I have a slightly weird problem that I'm looking for ideas on.harvey is a plan 9 kernel with a small number of differences as far as Go is concerned. The binary format is ELF. The system call calling convention follows the amd64 ABI, not the Plan 9 stack-based one. It's a true 64-bit ABI (Plan 9 ABI is really 32 bits) so we don't need to pass a pointer to Seek for a 64-bit value; it just goes in the 3rd register argument. So the weirdness of Seek for the Plan 9 ABI does not exist on Harvey. The system call numbers are the same as Plan 9.Aki Nyrhinen and I took a stab at a port to Harvey by doing the long task of finding all places that were plan 9 related (//build, *_plan9.go, etc.) and adding Harvey and it turned into quite a slog, and keeping up with ToT was impossible for our limited group. So, as a different experiment, I created a set of patches (567 lines total) that are applied to ToT, and thenI do aGOOS=plan9 make.bashand get a Go compiler that builds for Harvey and runs on Harvey.This method has worked for about a year: git pull the upstream master, then rebase a harvey branch on it, and my 3 small commits give me a working compiler. Almost all the tests pass, although I have yet to test in the last month or so.So the harvey compiler is "just like" plan 9 with small changes to 6 files.The effort of doing a full port is more than we have people for. I keep wondering if there's a way to express a port as "just like this other port except for these exceptions" -- or embed it in the naming of things, or in how things are found.I realize that this way probably lies madness, but thought I'd ask.
2) Partly because of the above, I don’t know how to effectively follow the “big ideas” of where Go is going. That place used to be golang-dev, but it seems like a lot more is now only on github. For example, I don’t think the (original) alias proposal was even mentioned on golang-dev until Dave’s email.
1) I know this isn’t your fault, but the github issue tracker isn’t as good as the code.google.com one was, at least for someone who is loosely trying to follow issues. It used to be I could skim the issues every now and then, and easily identify an issue I had previously seen by where I had starred. I’m not sure how to do that effectively in github, especially with the increased frequency of issues.
3) Another consequence of (1) is I may not see issues I can be helpful with. I just happened to look at the right time to see #17675, but even if I had triage powers, I don’t know that I would have seen it.
I'm definitely interested build system and trybots! :DMore testing machines for all the architectures etc. And speeding up the tests for sure!
This perhaps belongs to another email thread.
Shall I start another thread? I expected this discussion to die a quick death, but it seems I'm not the only one with this problem.
Having harvey include the plan 9 tag implicitly would *almost* work, but not quite. Consider this case:def_plan9_amd64.goThis is one of 5 files with that name pattern that I change for harvey.I'm pretty sure just having harvey imply plan 9 would include that file, still, and that would not work.
--
the // +build !harveyidea confuses me. If GOOS is harvey, files named *plan9* won't get built anyway. So adding that to those files is kind of a no op.
On Wed, Jan 4, 2017 at 3:32 PM, Daniel Martí <mv...@mvdan.cc> wrote:I think a good way to horizontally scale would be to better define what
people take care of what aspects or packages of the Go project. Then it
would be easier to add granularity and make space for more people,
taking some work off long-term contributors.I think this requires a bit of more structure and the presence of sub teams maybe. A few go-to people for each team, a written roadmap, summary of current projects and an accessible communication channel.
Does the build tool in this case establish an equivalence between plan 9 and harvey?
Happy 2017, Gophers.Before the Go 1.9 tree opens and before we start the regular mailing list planning thread about who's doing what during the 1.9 dev cycle, I wanted to start this separate thread about the health and tooling of the Go open source project.As Go continues to grow in usage and contributors, some parts of the Go project are not scaling as well as we'd like.In particular, there's an increasing number of bugs and code reviews being filed (to say nothing of the mailing list volume) and it's hard for people to keep up.At the same time, we've heard via surveys and email and indirect anecdotes that many people want to contribute to Go but either don't know how or don't feel welcome.To be explicit, we want and need your help. There's an increasing number of bugs to fix, bugs to triage, code to review, things to document, and tooling to improve.And despite the increasing number of bugs and code reviews, I think there's an even greater number of people who'd want to send bugs & code but are intimidated by the process.My main focus for the first half of the year will be working on the health and tooling for Go as an open source project to make sure it's easy and welcoming for people to send bugs and code, and that we have great tools, process, and documentation for processing incoming bugs and code.I have my own pet-peeve list of things I'd like to be smoother (below), but my perspective is skewed from being on the maintainer side for many years. I'm going to rely on the community to help point out the areas that are broken or at least not ideal.What do you find confusing or mysterious or intimidating about the Go project? Please reply here and/or file bugs. Let's fix it over the next few months.As some examples I can think of:* Flesh out the new "PriorDiscussion" wiki page (https://github.com/golang/go/issues/18430#issuecomment-270491909), so we give better answers and pointers to people in the future.* Start accepting Github PRs (with Gerrit integration). That is https://github.com/golang/go/issues/18517* Increase the number of non-Googlers with Github Issue/wiki access and access to various Gerrit permissions (https://golang.org/wiki/GerritAccess), and document more the process and policies for who gets what access, and when. That likely involves creating said policies, since it's somewhat random at the moment.* Integrate some non-Googlers into our weekly proposal review process more. A/V issues and timezones are always a challenge, but we should do something.* Make sure the Github issue labels are documented and used consistently. (https://github.com/golang/go/issues/18413)* Make sure contributors know what to expect, and the sometimes-implicit state diagram of the lifetime of a bug or code review is made explicit. (refining this implicit process as necessary as we document it and over time as we get experience with it)
* (Related to the prior item) Start load balancing the Github & Gerrit review load. Currently a few of us have tried to look at everything, and obviously that can't scale as Go grows. We need to load balance incoming code reviews & bugs for a first-pass review for obvious issues before marking them as ready for more thorough reviews. I don't have an exact plan yet. I'd like to figure this out with the community. To some extent an informal system has evolved (I see many people helping out in Github and Gerrit with incoming stuff, thanks!), but our tooling and documentation around it all is lacking.
Thanks for working on this, Brad.Last year I submitted a couple of small CLs to the Go project. I found it quite time-consuming to get up and running with an initial dev loop in which I could write, build, and run a single test. I remember that doing this without each time running the shell script that executes the entire test suite was somewhat nontrivial, and not well documented. For reference I've attached the instructions I wrote for myself to the end of this email -- perhaps from this you will be able to reconstruct what documentation was missing.It would have been helpful to have a very explicit tutorial on writing and running a test in the core codebase, all the way from cloning the repo to doing the one-time bootstrap stuff, to writing and running the test.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
> * Increase the number of non-Googlers with Github Issue/wiki access and access to various Gerrit permissions (https://golang.org/wiki/GerritAccess), and document more the process and policies for who gets what access, and when. That likely involves creating said policies, since it's somewhat random at the moment.
As some others have mentioned, even once access is granted, it can be difficult to determine (as an outside contributor) if you are the correct person to provide a review or approve a change. It would be nice to have some guidelines spelled out on what kind of changes are okay for outside contributors to review. I'd hate to give a +1/+2 and then immediately see a -2 after from a Go team member because I wasn't aware of some existing rule or the change was totally wrong.
* Improve the build system and trybots (as always)This is not a complete list by any means.What else needs work?