profile
viewpoint
Stephen Gutekanst slimsag Sourcegraph Arizona https://twitter.com/slimsag Developer @sourcegraph; "Crazy cat lady"; Aspiring gamedev; Faulty musician.

hexops/vecty 1816

Vecty lets you build responsive and dynamic web frontends in Go using WebAssembly, competing with modern web frameworks like React & VueJS.

slimsag/cgo-batching 9

CGO call batching benchmark

slimsag/cp 3

Chipmunk 2D physics wrapper for Go.

slimsag/9eyes 2

Raspberry Pi-based cat monitor for tracking feline inputs and outputs, weight

slimsag/appdash 2

Application tracing system for Go, based on Google's Dapper

slimsag/binpack 2

A Go implementation of Jake Gordon's 2D binpacking algorithm.

slimsag/darfree 1

Uses black magic to release memory on Darwin.

hexops/syndex 0

syndex performs language analysis via syntax-highlighting trees

rohanpai/shields 0

Shields badge specification, website and default API server

slimsag/archiver 0

Easily create and extract .zip, .tar.gz, .rar (extract-only), and .tar.bz2 files with Go

issue commentsourcegraph/sourcegraph

Distribution 3.21 Tracking issue

This week

This week I spent most of my time providing support internally and to customers, much more than usual. I did not make much headway against my planned work, but did add issues extensively for everything that came up to this milestone.

For customers, I provided extensive resource allocation advice to two major customers, and followed up extensively on ~7-8 more medium-sized customer issues before ultimately passing them off to other individuals or teams in order to reduce the number assigned to me.

Internally, I created a dev/testing managed instance and shared knowledge of them with the rest of the team in the form of updated docs, a recorded screencast, and improved tooling. I investigated ops issues with sourcegraph.com and multiple dev deployments with the team.

1:1s I had ran much longer than usual, leading to longer-form ongoing conversations. I also wrote a high-level progress summary on the Dhall work.

Next week:

I am hoping to be more heads-down and make substantial headway against my planned work, but acknowledge I have many more extensive conversations ahead of me which will be time consuming. Focus is key.

pecigonzalo

comment created time in 3 days

push eventsourcegraph/about

Stephen Gutekanst

commit sha b67a7b8d88ae43ed176c0c06477fcf31cb52828d

distribution: add missing header

view details

push time in 3 days

push eventsourcegraph/about

Stephen Gutekanst

commit sha 3f6ae6b675f749c07ccac1f70c3ae6a9d3d83091

distribution: add screencast for how to upgrade managed instances

view details

push time in 3 days

issue commenthexops/vecty

comparison between vecty and vugu?

Will indeed add a comparison page once we have the new website up.

xoviat

comment created time in 4 days

IssuesEvent

issue commenthexops/vecty

Add Vocexplorer to projects-using-vecty.md

Looks like a quite nice and complex UI, I'm sure many would be excited to see this!

I've gone ahead and added it exactly as you described above :)

NateWilliams2

comment created time in 4 days

push eventhexops/vecty

Stephen Gutekanst

commit sha 56dda858f26bff00a840f455a178b3ab076bb0fc

doc/projects-using-vecty: add Vocexplorer Closes #272

view details

push time in 4 days

issue closedhexops/vecty

Add Vocexplorer to projects-using-vecty.md

I've been working on this vecty application for a couple months and would love to have it featured on the projects-using-vecty document :-}

Vocdoni Block Explorer | A custom blockchain explorer for decentralized digital governance toolkit Vocdoni.io

closed time in 4 days

NateWilliams2

push eventsourcegraph/about

Stephen Gutekanst

commit sha f6dcd5db3cc702bbe16c098cc113b65851712eb3

managed instances: update creation process docs (#1630) Fixes some typos and broken links, etc.

view details

push time in 5 days

delete branch sourcegraph/about

delete branch : sg/mgd-creation

delete time in 5 days

PR merged sourcegraph/about

managed instances: update creation process docs

Fixes some typos and broken links, etc.

+11 -8

1 comment

1 changed file

slimsag

pr closed time in 5 days

issue closedsourcegraph/sourcegraph

Create a dev/testing managed instance

Breakout issue from https://github.com/sourcegraph/sourcegraph/issues/13604

closed time in 5 days

slimsag

issue openedsourcegraph/sourcegraph

navbar overflowing

https://sourcegraph.com/github.com/sourcegraph/zoekt/-/blob/cmd/zoekt-sourcegraph-indexserver/main.go#L58:10

image

created time in 6 days

PullRequestReviewEvent

issue openedsourcegraph/sourcegraph

Create a dev/testing managed instance

Breakout issue from https://github.com/sourcegraph/sourcegraph/issues/13604

created time in 6 days

PR opened sourcegraph/about

managed instances: update creation process docs

Fixes some typos and broken links, etc.

+11 -8

0 comment

1 changed file

pr created time in 6 days

create barnchsourcegraph/about

branch : sg/mgd-creation

created branch time in 6 days

issue commentsourcegraph/sourcegraph

Enable easier upgrades across multiple versions of Sourcegraph

Related (but not a complete solution for this): https://github.com/sourcegraph/sourcegraph/issues/9056

beyang

comment created time in 6 days

issue closedsourcegraph/sourcegraph

Clicking on search result clears search bar; have to refresh to get it back

Sourcegraph.com

repro:

  • visit sourcegraph.com/search
  • search for anything
  • click on any result

closed time in 7 days

dadlerj

issue commentsourcegraph/sourcegraph

Clicking on search result clears search bar; have to refresh to get it back

fixed https://sourcegraph.slack.com/archives/CMBA8F926/p1600734032009700

dadlerj

comment created time in 7 days

issue openedsourcegraph/sourcegraph

site ConfigMap changes on sourcegraph.com still require a pod restart

https://github.com/sourcegraph/sourcegraph/pull/13646#issuecomment-696451666 was merged which should have fixed this but for some reason it doesn't work still.

The configmap was updated properly, but the file on disk didn't appear to be updated so the frontend couldn't do anything.

This was the case for a little over an hour - maybe the cache times mentioned here need to be lowered or something? https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically

created time in 7 days

PullRequestReviewEvent

Pull request review commentsourcegraph/about

playbooks: document 'pod bouncing'

 watch -n1 kubectl get all -n prod -l app=gitserver -o wide ```  ### 4. Verify service is restored+ Open the alert UI to click on the check URL that was failing and verify it's now working again. +## Restarting pods++This action is also referred to as "bouncing pods" or to "bounce a pod". Follow the steps to [authenticate kubectl](../../deployments.md) and perform a restart using kubectl to restart the desired deployment:++```sh+kubectl rollout restart deployment/$SERVICE+```++Note the use of `deployment/` - you cannot restart services (`svc/`). Note that [stateful sets have a different process](#making-updates-to-stateful-sets).
Note the use of `deployment/` - you cannot restart services (`svc/`). Note that [stateful sets have a different process](#making-updates-to-stateful-sets).

You can also bounce pods by manually finding them via `kubectl get pods` and `kubectl delete pod $POD_ID`. Once a pod is deleted, it will automatically be recreated.
bobheadxi

comment created time in 7 days

PullRequestReviewEvent

pull request commentsourcegraph/sourcegraph

conf: watch for changes in config override files

@keegancsmith it seems this does not work in practice for some reason. Perhaps updating a configmap does not actually cause the file to change on disk in k8s? See https://sourcegraph.slack.com/archives/CMBA8F926/p1600734032009700

keegancsmith

comment created time in 7 days

issue commentsourcegraph/sourcegraph

Clicking on search result clears search bar; have to refresh to get it back

Looks like this has been fixed and is in 3.20.1 but not yet on sourcegraph.com for some reason.

image

https://github.com/sourcegraph/sourcegraph/pull/13954

dadlerj

comment created time in 7 days

issue commentsourcegraph/sourcegraph

Clicking on search result clears search bar; have to refresh to get it back

Just came here to file exactly this. It is infuriating for me as it breaks my most common workflow:

  1. Visit https://sourcegraph.com/github.com/sourcegraph/sourcegraph and search for something like Your license will expire trying to track down where it comes from.
  2. Find the relevant file, and want to now search for its usages by searching in the repo for LicenseExpirationAlert - but wait - now my search bar is empty. How the heck do I come up with the right repo: concoction? Now I am out of context

Was this a regression? Is this also a regression in 3.20 or only Sourcegraph.com?

dadlerj

comment created time in 7 days

issue closedsourcegraph/sourcegraph

syntect-server freeport detection failing

A customer https://app.hubspot.com/contacts/2762526/company/693777200 / https://sourcegraph.slack.com/archives/C011899KB6U/p1597363626348700 reports syntect-server is failing in their EKS cluster with nothing other than:

2020/08/14 00:06:27 worker command: env ROCKET_PORT={{.Port}} /syntect_server
2020/08/14 00:06:27 failed to find free port
2020/08/14 00:06:27 failed to find free port
2020/08/14 00:06:27 failed to find free port
2020/08/14 00:06:27 failed to find free port
2020/08/14 00:06:28 failed to find free port

This behavior happened only recently with no prior changes, indicating that freeport detection was working before in the same deployment but no longer is.

Most likely, this is caused by syntect-server's workers dying and allocating new ports - leading to ephemeral port exhaustion on the EKS host node. However, the logs which indicate which files are problematic appear to not be present (most likely they were paged out due to the number of "failed to find free port" messages.)

https://github.com/sourcegraph/syntect_server makes use of the freeport Go package to spawn worker processes. That package has a number of reported failures 1 2 3 about its localhost-based resolution.

We should adopt a different package and/or https://github.com/phayes/freeport/pull/8 for port allocation and see if that resolves the issue.

closed time in 7 days

slimsag

push eventslimsag/syntect

Stephen Gutekanst

commit sha c1252e79bbd34f213e4ce8a58f70923dfecb35f9

make assets (Rust stable 1.46.0)

view details

push time in 11 days

push eventslimsag/syntect

Ninjani

commit sha 39cb3c9a6c8137f6cd30dd7f58a6dfce134f405c

Add the-way to "Projects using Syntect"

view details

Tristan Hume

commit sha 064ae755f77e4a4d0cb5c80b64eb27c5c3507df4

Merge pull request #290 from out-of-cheese-error/master Add The Way to "Projects using Syntect"

view details

Vincent Prouillet

commit sha 26854821c73578dd25d368eefdf8b9e56c1ea397

Update dependencies

view details

quasicomputational

commit sha b88b9dbff3b7b550a59f1abac64d01cb138df7fc

html: allow a configurable prefix on CSS class names. CSS class names are a global namespace. Without some kind of namespace partitioning, it's entirely possible to have class name collisions and all sorts of chaos as different sources of CSS stomp on each other. Hence, add a new `ClassStyle`, `SpacedPrefixed`, which tells syntact to add a configurable prefix to all of the class names that it uses. This patch breaks the API. Some of the breakage is not strictly necessary (e.g., `ClassedHTMLGenerator::new` could stay as it is, and a `new_with_style` method added). However, some is enforced: `ClassStyle` can no longer be `Copy` because it can now contain a `String`, and so `tokens_to_classed_spans` must now accept a reference. Because this is a breaking API change anyway, I took the opportunity to add `ClassStyle` parameters where relevant, to make the parametricity of `ClassedHTMLGenerator` and `css_for_theme` clear.

view details

quasicomputational

commit sha 5a48a18a7fbe78c912fb06a94dd5bf57395df760

Fix a doctest.

view details

quasicomputational

commit sha 1e00460e8f9ba3d462a30e7f00d89e6443fe96ad

html: switch ClassStyle to hold a &str instead of String. This proves to be nicer to use, not least because now a `const` `ClassStyle` can be declared. It's also now `Copy` again. It's still technically an enforced breaking change because of the added lifetime parameter, though I doubt whether any actually extant code would be broken. On that basis I've kept the unforced breaks as well, since I do think they add value (primarily, misuse resistance).

view details

quasicomputational

commit sha f5ad8d14f20196560263e15a529bf7a6d245b2af

Delete now-outdated comment.

view details

Tristan Hume

commit sha 1c7e27af8bcd0a3398219c357c7351da337d0ec7

Merge pull request #293 from Keats/master Update dependencies

view details

Tristan Hume

commit sha b2360ea01adb0cf1d0ac2f41263741af6723fb87

Changelog for v4.2.0

view details

quasicomputational

commit sha dbc28335bdc58902c858fe3314a911f8bd2f3324

html: use &'static str for the class name prefix. This removes the enforced API breaks altogether. The unforced breakage is also reverted; now, the methods that assumed `Spaced` are deprecated, and new parameterised ones are provided.

view details

quasicomputational

commit sha 0e9785657ed4547be97d3b75e579de80188f4f4e

html: factor the loop in scope_to_*. If this turns out to be undesirable for any putative future class styles, it can always be reverted.

view details

quasicomputational

commit sha 1336aa015aa1d9a437b28e3ddc7c4ee2f53777a6

html: add non_exhaustive to ClassStyle.

view details

Tristan Hume

commit sha f444f604f6b96f5f6c17cb63a84f891f69516586

Merge pull request #296 from quasicomputational/css-class-namespaced html: allow a configurable prefix on CSS class names.

view details

Keith Hall

commit sha abfb32cf9b27bdd28e54b271d5ce5f6065cc2453

remove dependency on assets for html feature - just use it for tests

view details

Tristan Hume

commit sha a461eec20578369c423c524fb32f0eda303e5d6a

Merge pull request #300 from forkeith/html-assets-dependency remove dependency on assets for html feature - just use it for tests

view details

Tristan Hume

commit sha 83eb0c3734d2114ac10dd5724f2c2c3c6f4fc617

Bump to v4.3.0

view details

Nathan West

commit sha 91bce27b14959193e745b487fd22c5e07714097a

Errors are now Send + Sync

view details

Nathan West

commit sha 65590f9b6cca8598676dfbcda4cb89290865c16f

Added 'static

view details

Tristan Hume

commit sha d322b26591a77207f5e711cec6b20a38dff8c701

Merge pull request #304 from Lucretiel/sync Errors are now Send + Sync + 'static

view details

Tristan Hume

commit sha 1ea232d1f6553e62ed3f135c1bc5710089bd1be2

Bump to v4.4.0

view details

push time in 11 days

push eventslimsag/syntect

Stephen Gutekanst

commit sha 67d1bd2fb890e2ee263a58742fed39c0dea149f3

Packages: update to remove GraphQL, INI, Perforce, TOML See https://github.com/sourcegraph/sourcegraph/issues/13933

view details

push time in 11 days

push eventslimsag/Packages

Stephen Gutekanst

commit sha afbada0dff69d2639e898d27b5a814fd839b8c97

GraphQL: Remove non-open-source grammar (no license) See: - https://github.com/sourcegraph/sourcegraph/issues/13933 - https://github.com/dncrews/GraphQL-SublimeText3/issues/11

view details

push time in 11 days

push eventslimsag/Packages

Stephen Gutekanst

commit sha 30db674c14cf8cb627f7091f3677e58a3ac656c2

TOML: Remove non-open-source grammar (no license) See: - https://github.com/sourcegraph/sourcegraph/issues/13933 - https://github.com/lmno/TOML/issues/4

view details

Stephen Gutekanst

commit sha a1223e7fee47fcb4756c88a6f3a28c0d3682c800

INI: Remove non-open-source grammar (no license) See: - https://github.com/sourcegraph/sourcegraph/issues/13933 - https://github.com/clintberry/sublime-text-2-ini#credits

view details

push time in 11 days

push eventslimsag/Packages

Stephen Gutekanst

commit sha 688b03c7e2163ee3708f9af14b2e8c15dc7fa03a

Perforce: remove grammar incompatible with commercial software See https://github.com/sourcegraph/sourcegraph/issues/13933

view details

push time in 11 days

issue openedsourcegraph/sourcegraph

Add syntax highlighting for TOML files (develop an open-source grammar for it)

The syntax definition we used for highlighting TOML files before was found to have no license and not be open-source so we had to remove it. See #13933

We should develop and open-source grammar for it following what was said in #13933 - please see that issue if you are interested in taking a shot at this. We are looking for volunteers :)

created time in 11 days

issue openedsourcegraph/sourcegraph

Add syntax highlighting for INI files (develop an open-source grammar for it)

The syntax definition we used for highlighting INI files before was found to have no license and not be open-source so we had to remove it. See #13933

We should develop and open-source grammar for it following what was said in #13933 - please see that issue if you are interested in taking a shot at this. We are looking for volunteers :)

created time in 11 days

issue openedsourcegraph/sourcegraph

Add syntax highlighting for GraphQL (develop an open-source grammar for it)

The syntax definition we used for highlighting GraphQL files before was found to have no license and not be open-source so we had to remove it. See https://github.com/sourcegraph/sourcegraph/issues/13933

We should develop and open-source grammar for it following what was said in #13933 - please see that issue if you are interested in taking a shot at this. We are looking for volunteers :)

created time in 11 days

issue openedsourcegraph/sourcegraph

Add syntax highlighting for Perforce (develop an open-source grammar for it)

We used to use this syntax definition for highlighting Perforce files before Sourcegraph v3.21, but had to remove it as we discovered it was GPLv2 licensed which would require us to license https://github.com/sourcegraph/syntect_server as GPLv2 as well.

We should develop and open-source grammar for it following what was said in https://github.com/sourcegraph/sourcegraph/issues/13933

created time in 11 days

issue commentsourcegraph/sourcegraph

Remove syntax highlighting for GraphQL, INI file, TOML, and Perforce

FYI cc @christinaforney - no action for you to take here but something to be aware of.

slimsag

comment created time in 11 days

issue openedsourcegraph/sourcegraph

Remove syntax highlighting for GraphQL, INI file, TOML, and Perforce

Why remove syntax highlighting or these languages?

A review of syntect_servers' included syntax definitions found the syntaxes we include for four languages have questionable licenses:

  • GraphQL: No license. Cannot legally use/include, period. https://github.com/dncrews/GraphQL-SublimeText3/issues/11
  • INI files: No traceable authorship/license. Cannot legally use/include, period. https://github.com/clintberry/sublime-text-2-ini#credits
  • TOML: Trail of authorship, but not open-source / has no license. Cannot legally use/include under any circumstances. https://github.com/lmno/TOML/issues/4
  • Perforce: GPLv2 licensed. Could include, but would require a fair amount of engineering effort to not statically link syntax definitions OR would require licensing syntect_server itself under GPLv2, which I am strongly opposed to. https://github.com/textmate/perforce.tmbundle#licensing

How we plan to add them back

I fully recognize that losing syntax highlighting for these languages, particularly the first three, sucks.

It is my hope that anyone will take up the task of writing a syntax definition for these languages - which could be quite fun and can be done completely independently of Sourcegraph either in TextMate or Sublime Text. Once one exists that has a standard license used in every other syntax definition out there (Apache, BSD, MIT, or the Common License used in TextMate grammars), then we can include it in syntect_server and Sourcegraph easily.

To add syntax highlighting for one of these languages, you will need to write one of the following:

  • A .sublime-syntax grammar https://www.sublimetext.com/docs/3/syntax.html
  • Or a TextMate .tmLanguage grammar https://macromates.com/manual/en/language_grammars

There are many resources online for how to develop and test these right in Sublime or TextMate, and you can find many examples in the syntaxes we currently include in https://github.com/slimsag/Packages#license

created time in 11 days

issue closedsourcegraph/sourcegraph

Stephen's Dhall PoC

Time tracking issue for myself to present a Dhall PoC

closed time in 11 days

slimsag

issue commentsourcegraph/sourcegraph

Stephen's Dhall PoC

https://github.com/sourcegraph/slimsag-poc-dhall - based on discussion last night I plan to stop working on this and begin contributing to Geoffrey's arch as part of 3.21 and beyond. Recording available

slimsag

comment created time in 11 days

push eventsourcegraph/slimsag-poc-dhall

Stephen Gutekanst

commit sha 5b3bb2b34cf8efecf50969eef7be60f8b034b6b5

fixup

view details

push time in 12 days

issue commentsourcegraph/sourcegraph

RFC 235: Add code intel postgres container

pure-docker also needs to be done

efritz

comment created time in 12 days

pull request commentsourcegraph/sourcegraph

monitoring: Ensure code intel is alert target of all code intel metrics

Thanks for spearheading this! LGTM

efritz

comment created time in 12 days

issue commentsourcegraph/sourcegraph

release steps: stop posting milestone triage messages

@nicksnyder completely agree that needs to happen - my point is individual teams are better equipped to do that and I suspect are doing that today while ignoring these spammy reminders.

slimsag

comment created time in 12 days

issue openedsourcegraph/sourcegraph

Improve reliability of "e2e regression" tests

Today we have "e2e regression" tests at https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/web/src/regression/README.md which perform a number of QA tests.

We cannot release without these passing, yet a majority of the time these are failing by the end of the iteration.

This is a tracking issue for us to improve the reliability of them. We should identify ways to make certain they are reliable, even if it means they run slowly and e.g. have long sleep statements between steps.

This is a broad issue because the problem is broad - there are a lot of tests and this will need to be done on a case-by-case basis. This is a tracking issue for that work, which should be linked as an issue below:

  • [] TODO: link to other issues about improving reliability here.

created time in 12 days

issue openedsourcegraph/sourcegraph

Identify further ways to reduce number of steps needed to complete a release

Our release process is a quite long checklist, e.g.: https://github.com/sourcegraph/sourcegraph/issues/13374

I have filed a number of issues with the lowest-hanging fruit I see to remediate the situation: https://github.com/sourcegraph/sourcegraph/issues?q=is%3Aissue+is%3Aopen+label%3Ateam%2Fdistribution+project%3Asourcegraph%2F90

Once the above has been mostly addressed, we should re-evaluate and identify further ways we can reduce the number of steps needed to complete a release. The outcome of this issue should be more issues detailing those opportunities.

created time in 12 days

issue openedsourcegraph/sourcegraph

Explore making it easier to run Kubernetes cluster smoke tests

Today our release process https://github.com/sourcegraph/sourcegraph/issues/13374 indicates you should create a Kubernetes cluster, deploy Sourcegraph on it, run the e2e test initializer on it, and run the regression test suite on it:

  • [ ] New Sourcegraph Kubernetes cluster:
    • Run the initializer on a new Sourcegraph Kubernetes cluster.
    • Run the regression test suite.

There has to be a better way we can reduce the number of manual steps here, maybe using Pulumni or some other form of scripting for this. Let's investigate and find possible opportunities, even if we don't get around to actually implementing them in 3.21.

created time in 12 days

issue openedsourcegraph/sourcegraph

add vagrant test for sourcegraph/server upgrades

Today our release process https://github.com/sourcegraph/sourcegraph/issues/13374 indicates we should do a manual test of upgrading Sourcegraph using the server image:

  • [ ] Upgrade from previous release:
    • Run the initializer on a Docker container running the last patch version of the previous major/minor release.
    • Upgrade and run the regression test suite.

We should effectively copy what we did for https://github.com/sourcegraph/deploy-sourcegraph-docker/tree/master/test and have a Vagrant-based test for this that runs in CI.

created time in 12 days

issue openedsourcegraph/sourcegraph

run "e2e regression tests" in CI once/day, even if they fail all the time

We should be able to run the e2e regression tests described in our release process https://github.com/sourcegraph/sourcegraph/issues/13374 in our CI pipeline:

  • [ ] Run regression tests:
    • [ ] Follow README.md to set up your e2e environment. Run the tests from the web directory. A more complete set of env vars can be found in this 1password entry.
    • [ ] New Sourcegraph Docker container:
      • Run the initializer: E2E_INIT=true SOURCEGRAPH_BASE_URL=http://localhost:7080 yarn run test:regression -t 'Initialize new Sourcegraph instance'
      • Run the regression test suite: SOURCEGRAPH_BASE_URL=http://localhost:7080 yarn run test:regression

Actually having these pass is going to not be likely possible in 3.21, but we should aim to have them running (even if they fail all the time) in CI once per day.

created time in 12 days

issue openedsourcegraph/sourcegraph

release steps: stop announcing release candidates

Today our release process https://github.com/sourcegraph/sourcegraph/issues/13374 has us announce to #dev-announce in Slack that release candidates have been created. This makes releases eventful and, I believe, gives the impression that there is some extensive testing of release candidates going on when in practice it is just basic smoke tests and all extensive testing should've been done before any change was merged.

I also believe that most team members do not actually care for or act on these messages, so they are spammy. We should stop sending them, remove the associated scripts (yarn run release release-candidate:dev-announce 3.20.0-rc.1) and steps from the release process tracking issue.

created time in 12 days

issue openedsourcegraph/sourcegraph

release steps: automate CHANGELOG version header creation

Today our release process requires we manually edit the CHANGELOG to change "Unreleased" to the current version and add a new section for "Unreleased" that is empty:

  • [x] Add a new section ## 3.MINOR to CHANGELOG.md immediately under ## Unreleased changes. Add new empty sections under ## Unreleased changes (example).
  • [x] Commit this CHANGELOG edit to main using a PR.
  • [x] Create the 3.20 branch off the CHANGELOG commit in the previous step: git branch 3.20 && git push origin 3.20.

These steps should be automated as part of our release scripts.

created time in 13 days

issue openedsourcegraph/sourcegraph

release steps: do not verify CHANGELOG entries

Our current release process https://github.com/sourcegraph/sourcegraph/issues/13374 indicates that the release captain should:

  • [x] Verify for each CHANGELOG item the following (if any item does not have these, disable it, notify the owner, and remove it from the CHANGELOG):
    • It has an owner attached to it
    • It has undergone manual QA (and the QA was done on k8s.sgdev.org or at scale if the feature requires it).
    • It is covered by the regression test suite

In practice I do not think this is something the release captain can, or actually does, well. Yes it sounds ideal that every change is verified to have an owner, has undergone QA at scale, and is covered by regression tests - but I seriously doubt the release captain is actually able to effectively do this. Do they look at every commit since the last release and message every author? I doubt it.

I propose removing this and leaving it up to individual teams and dev practices to ensure this has happened. We can update handbook docs to make it clear that we expect this to be done for all changes to a reasonable degree (but I think that is already assumed by most, and perhaps already documented.)

created time in 13 days

issue openedsourcegraph/sourcegraph

release steps: stop posting milestone triage messages

Today our release process has us posting these messages to most GitHub issues before the release https://github.com/sourcegraph/sourcegraph/issues/13792#issuecomment-692254942

Dear all,

This is your release captain speaking. 🚂🚂🚂

Branch cut for the 3.20 release is scheduled for tomorrow.

Is this issue / PR going to make it in time? Please change the milestone accordingly. When in doubt, reach out!

Thank you

I have multiple issues with this:

  1. It makes releases eventful and the wording appears to be putting pressure to land a change ASAP ("release is tomorrow, is this going to make it?") which is not what I want.
  2. It is spammy, and I do not think many people take action on it.

My proposal is to stop posting these messages all together and remove that step/script from our release process:

  • [x] Use ./dev/release-ping.sh to ping teammates who have open issues or PRs in the milestone to ask them to triage those that won't make it into the release.

Individual teams are then responsible for updating milestones on issues are part of their planning - which they are (or are not) already doing today.


Related Slack thread https://sourcegraph.slack.com/archives/C02FSM7DU/p1600112057111500

@efritz says:

Have/do engineers find the branch-cut-imminent reminder being posted to each open issue in the milestone useful?

@rvantonder says:

No.

@unknwon says:

For individual issues, it is useful, but the email spam it causes outweighs the usefulness for me.

@efritz says:

How do you find it useful? I’d like to understand the benefit others see in it.

@unknwon says:

Personally I use it as a signal to post a status update comment, basically decide should I

  1. Put into backlog if priority dropped
  2. Move to candidate list for next iteration if still a priority but no bandwidth
  3. I'm currently working on it as last few items for the iteration, confident to ship, ignore the comment (also true for items only meaningful for Sourcegraph Cloud, which doesn't really care the branch cut). With that said, current "reminder comments" is not the only way to achieve what I've been using it for. (so if it annoys most of us, I'm positive to remove it)

@efritz says:

That makes sense. Do you think it’s a better reminder on the issue rather than having some other signal (branch cut is on calendar, announced in slack, etc) that won’t necessarily stick itself inside of an issue discussion?

@keegancsmith says:

I think in theory the idea is if your issue was supposed to be completed in that milestone, you should hopefully have everyone closed or just one or two that get commented on. So this encourages breaking down longer issues into smaller issues which just target a single milestone. The downside of this is it somewhat dictates how you manage and plan your issues, the upside is when looking at the issues as an outsider for a milestone you can be confident is the expectation is to actually get all that work done.

cc @sourcegraph/distribution please discuss

created time in 13 days

issue openedsourcegraph/sourcegraph

release steps: stop posting messages about branch cut in Slack

Today our release tracking issue has us always do the following step 5 work days before the release:

  • [x] Post to #dev-announce the following message:
    :captain: *Release captain announcement:*
    
    Branch cut will be at the start of the next working day (2020-9-15).
    
    All changes that will be part of `3.20` (and all associated CHANGELOG updates) should be in `main` by tomorrow. Otherwise, they will not be included in the release.
    

This is redundant with what we post in GitHub issues already which spam's peoples email inboxes, and also makes releases eventful ("you have one day to merge your changes!!!") which I want to avoid. Let's stop doing this..

created time in 13 days

issue commentsourcegraph/sourcegraph

release: make Product team self-sufficient

Whoops, posted under wrong account.

sourcegraph-bot

comment created time in 13 days

issue commentsourcegraph/sourcegraph

SourceGraph fails to find results in repos unless "repo:<prefix>" is specified. Reports "nnn Repositories Not Found"

The problem and repositories reported missing indicates that the search indexer is in accessible over the network or it is failing to index your repositories.

This is a single-docker container deployment, I presume? How many repositories do you have on it? What do the logs look like? (You can send them to stephen@sourcegraph.com)

rthille

comment created time in 13 days

issue commentsourcegraph/sourcegraph

managed-instances: deploy a demo instance

Would this replace k8s.sgdev.org?

No, maybe "managed-dev.sourcegraph.com" would be a better name for the test one - the aim would be to have a "test" deployment we can freely muck around with.

bobheadxi

comment created time in 13 days

pull request commentsourcegraph/sourcegraph

Replace fmt.Sprintf with equivalent strconv.Itoa

It looks like some instances here could potentially be introducing bugs as they are turning an int64 -> int first.

Also, some instances are needlessly wrapped with an int conversion it seems?

mrnugget

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsourcegraph/deploy-sourcegraph

rework versioning and release scheme

+#!/bin/bash++CONSTRAINT=$1++update-docker-tags \+  -enforce="sourcegraph/cadvisor=$CONSTRAINT" \+  -enforce="sourcegraph/frontend=$CONSTRAINT" \+  -enforce="sourcegraph/jaeger-agent=$CONSTRAINT" \+  -enforce="sourcegraph/github-proxy=$CONSTRAINT" \+  -enforce="sourcegraph/gitserver=$CONSTRAINT" \+  -enforce="sourcegraph/grafana=$CONSTRAINT" \+  -enforce="sourcegraph/indexed-searcher=$CONSTRAINT" \+  -enforce="sourcegraph/search-indexer=$CONSTRAINT" \+  -enforce="sourcegraph/jaeger-all-in-one=$CONSTRAINT" \+  -enforce="sourcegraph/postgres-11.4=$CONSTRAINT" \+  -enforce="sourcegraph/precise-code-intel-bundle-manager=$CONSTRAINT" \+  -enforce="sourcegraph/precise-code-intel-worker=$CONSTRAINT" \+  -enforce="sourcegraph/prometheus=$CONSTRAINT" \+  -enforce="sourcegraph/query-runner=$CONSTRAINT" \+  -enforce="sourcegraph/redis-cache=$CONSTRAINT" \+  -enforce="sourcegraph/redis-store=$CONSTRAINT" \+  -enforce="sourcegraph/repo-updater=$CONSTRAINT" \+  -enforce="sourcegraph/searcher=$CONSTRAINT" \+  -enforce="sourcegraph/symbols=$CONSTRAINT" \

Can we do -enforce="sourcegraph/.*=$CONSTRAINT" to cover them all without explicitly listing each?

bobheadxi

comment created time in 14 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

Prevent password reset code leakage via cross origin requests

 	<meta http-equiv="x-ua-compatible" content="ie=edge"> 	<meta name="google" content="notranslate"> 	<meta http-equiv="Content-Language" content="en">-	<meta name="viewport" content="width=device-width, viewport-fit=cover" />+    <meta name="viewport" content="width=device-width, viewport-fit=cover" />+    <meta name="referrer" content="origin-when-cross-origin"/>
	<meta name="referrer" content="origin-when-cross-origin"/>
ElizabethStirling

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

Prevent password reset code leakage via cross origin requests

 	<meta http-equiv="x-ua-compatible" content="ie=edge"> 	<meta name="google" content="notranslate"> 	<meta http-equiv="Content-Language" content="en">-	<meta name="viewport" content="width=device-width, viewport-fit=cover" />+    <meta name="viewport" content="width=device-width, viewport-fit=cover" />
	<meta name="viewport" content="width=device-width, viewport-fit=cover" />
ElizabethStirling

comment created time in 14 days

PullRequestReviewEvent

issue commentsourcegraph/sourcegraph

License report for syntect_server & its dependencies; remove syntaxes with questionable licenses

I will do this after the branch cut so it goes out in 3.21 and we have as much time as possible to gauge reactions/feedback internally on this change, and if needed additional time to do mitigation work such as e.g. creating our own GraphQL syntax.

slimsag

comment created time in 14 days

issue commentsourcegraph/sourcegraph

Distribution 3.20 Tracking issue

Last week

Interviewed Cloud and CE candidates, overhauled customer-facing managed instance docs, brainstormed LSIF postgres move with Eric. Chatted with https://app.hubspot.com/contacts/2762526/companies/list/view/all/?query=apple about multi-region deployments and more. Figured out next steps of Dhall with Uwe and Geoffrey and swapped some of my planned work to help out further there, spending about ~6h total on my Dhall PoC.

This week

Close out my planned work for this iteration, 3.21 planning.

pecigonzalo

comment created time in 14 days

issue commentsourcegraph/sourcegraph

Run e2e "regression" tests on bare-metal Buildkite agents on every commit to master (non-blocking)

@davejrt has beaten me quite a lot in looking into this and https://github.com/sourcegraph/sourcegraph/issues/12339 (which covers the needlessly-separate e2e test suite), but we still have a little ways to go. I am pulling into 3.21, I suspect only a few days of work remaining before we have this in place. cc @pecigonzalo

slimsag

comment created time in 14 days

issue openedsourcegraph/sourcegraph

Stephens

  • Sourcegraph version: <!-- the version of Sourcegraph or "Sourcegraph.com" -->
  • Platform information: <!-- OS version, cloud provider, web browser version, Docker version, etc., depending on the issue -->

Steps to reproduce:

Expected behavior:

Actual behavior:

created time in 14 days

PullRequestReviewEvent

pull request commentsourcegraph/sourcegraph

Document when to introduce new services or not

Deferring to 3.21. I still intend to follow-up on this, but a higher-priority problem came up.

slimsag

comment created time in 14 days

pull request commentsourcegraph/about

distribution: add monitoring architecture page

Deferring to 3.21. I still intend to follow-up on this, but a higher-priority problem came up.

slimsag

comment created time in 14 days

pull request commentsourcegraph/sourcegraph

Remove links to pure-docker

Unfortunately in some cases like this the linter can be SUPER unclear

pecigonzalo

comment created time in 14 days

pull request commentsourcegraph/sourcegraph

Remove links to pure-docker

I think the linter is complaining because the sidebar is linking to the cluster doc on every page: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/sourcegraph/sourcegraph%24%40gp/dyi-deployment+file:doc+/cluster&patternType=literal

pecigonzalo

comment created time in 14 days

Pull request review commentsourcegraph/sourcegraph

Remove links to pure-docker

-# Installing Sourcegraph on a cluster

Would be great to document this somewhere, I had to go digging for it

pecigonzalo

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

Remove links to pure-docker

-# Installing Sourcegraph on a cluster

https://sourcegraph.com/github.com/sourcegraph/sourcegraph@gp/dyi-deployment/-/blob/doc/_resources/assets/redirects

Once updated the docsite pod will need to be rebooted

pecigonzalo

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

Remove links to pure-docker

-# Installing Sourcegraph on a cluster

Please add a redirect for this page for Google

pecigonzalo

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

Remove links to pure-docker

  | Deployment Type                                       | Suggested for                                       | Setup time | Multi-machine? | Auto healing? | Monitoring? | |-------------------------------------------------------|-----------------------------------------------------|------------|----------------|---------------|-------------|-| [Single-container server](../install/docker/index.md) | Local testing                                       | 60 seconds | Impossible     | No            | No          |-| [Docker Compose](../install/docker-compose/index.md)  | Small & medium production deployments               | 5 minutes  | Possible       | No            | Yes         |-| [Kubernetes](../install/cluster.md)                   | Medium & large highly-available cluster deployments | 30 minutes | Easily         | Yes           | Yes         |+| [Single-container server](../install/docker/index.md) | Local testing                                       | 60 seconds | No             | No            | No          |+| [Docker Compose](../install/docker-compose/index.md)  | Small & medium production deployments               | 5 minutes  | Not Supported  | No            | Yes         |+| [Kubernetes](../install/kubernetes/index.md)          | Medium & large highly-available cluster deployments | 30 minutes | Yes            | Yes           | Yes         | -* If you're just starting out, we recommend [running Sourcegraph locally](docker/index.md). It takes only a few minutes and lets you try out all of the features. +* If you're just starting out, we recommend [running Sourcegraph locally](docker/index.md). It takes only a few minutes and lets you try out all of the features. * If you need scalability and high-availability beyond what a single-node [Docker Compose](https://docs.docker.com/compose/) can offer, use the [Kubernetes cluster deployment option](https://github.com/sourcegraph/deploy-sourcegraph), instead.+* Other deployment types are **not supported**.

I do not think we need to state this, we just need to state was is supported.

pecigonzalo

comment created time in 14 days

PullRequestReviewEvent

push eventslimsag/kastle

Stephen Gutekanst

commit sha 0f525f3203babef80fbb21905c0ea10e449c946d

blueprints etc

view details

push time in 15 days

push eventslimsag/kastle

Stephen Gutekanst

commit sha 8cc41c24ba2e1ac4fc7e5f857ce496cffd43d5c5

blueprints

view details

push time in 15 days

push eventslimsag/kastle

Stephen Gutekanst

commit sha 65591e1f5d5f2512e21291f96144e7723006c1a2

Add files via upload

view details

push time in 15 days

create barnchslimsag/kastle

branch : master

created branch time in 15 days

created repositoryslimsag/kastle

created time in 15 days

push eventsourcegraph/about

Stephen Gutekanst

commit sha dcad8ebad93761ca3b07ab6793c9566227232e74

Distribution: add team logo, make us sound cool (#1560) I saw other teams are [adding team logos](https://sourcegraph.slack.com/archives/CHPC7UX16/p1599821264116400) to their handbook pages, so I want to add one for us and edited wording to make us sound cool 😄

view details

push time in 17 days

delete branch sourcegraph/about

delete branch : sg/distribution-logo

delete time in 17 days

PR merged sourcegraph/about

Distribution: add team logo, make us sound cool

I saw other teams are adding team logos to their handbook pages, so I want to add one for us and edited wording to make us sound cool 😄

Rendered: https://github.com/sourcegraph/about/blob/sg/distribution-logo/handbook/engineering/distribution/index.md

+3 -1

1 comment

1 changed file

slimsag

pr closed time in 17 days

pull request commentsourcegraph/about

Distribution: add team logo, make us sound cool

(disclaimer: I bribed my artist sister to make this a long while back)

slimsag

comment created time in 17 days

pull request commentsourcegraph/about

Code intel: add team logo, we already sound cool

efritz

comment created time in 17 days

pull request commentsourcegraph/about

Code intel: add team logo, we already sound cool

🤣 looks like the intro to the illuminati videos I watch on YouTube

efritz

comment created time in 17 days

PR opened sourcegraph/about

Distribution: add team logo, make us sound cool

I saw other teams are adding team logos to their handbook pages, so I want to add one for us and edited wording to make us sound cool 😄

+3 -1

0 comment

1 changed file

pr created time in 17 days

create barnchsourcegraph/about

branch : sg/distribution-logo

created branch time in 17 days

more