deephaven / deephaven-core Goto Github PK

We need to choose a place where to host our package artifacts - ideally, every single commit / PR for some period of time.

For official releases, we should use Maven Central / Docker Hub.

I think it's worth investigating https://docs.github.com/en/packages/learn-github-packages/about-github-packages - it's in beta and free for now. Supports Docker/npm/Gradle.

• out of order dependency timeout
• cyclical dependency detection
• remove failed/cancelled/released exports from exportMap after a timeout

Create a CONTRIBUTING.md document that outlines the steps to create a pull request, and how to get it reviewed, approved, and merged. This will be internal facing for now, and should be updated/evolve as we prepare to engage with the community.

Somehow need to be able to select what kind of session to make. This is probably just revising the ConsoleCreator.jsx to remove all of the options except for one dropdown which selects the session type as defined by the server.

Clean up the ColumnSource classes
Ripping out ones that are not in MVP

App-specific header will be a flatbuffer with columns, index, and "use pos space" boolean, plus others.

This ensures our client will be able to read plain flight payloads, and that plain flight clients can read data at least in a way they expect.

App-specific header will be a flatbuffer with columns, index, and "use pos space" boolean, plus others.

Separate the Web UI grid into it's own component/project and import it into the core.

This could let GRPC clients send commands before earlier ones have even been handled and not need to worry about them getting mis-ordered in the http2 proxy/server.

Instead, for now clients must wait until their previous command completed before starting the next one.

DoPut has out-of-band sequencing for BarrageMessage's. This logic should be lifted, and unit tested, for re-use by patterns like these. (See the usage of RAPriQueue in FlightServiceGrpcImpl.)

Define the versioning process used and put in the README.md.
An example would be https://semver.org/

Suggest that we simply have a master branch, then we tag it with a release, and create a branch for that with patch versioning if necessary.

Restore the layout from when they close/re-open a session.

Need to remove outdated references to Illumon, maybe iris, fishlib, and genesis. For example, a couple of property keys explicitly reference genesis.

Edit to add description: this ticket refers to the an initial release of the actual code and product. There are some prerequisite skeleton structure that can be setup - but there needs to be care before any actual code is released (these can be described in their own tickets).

Specify a styleguide to use (eg. https://google.github.io/styleguide/) in the README.md of the project.

Replace all references to FontAwesome icons with our own icons or another free alternative.

Details for sub issue 1

Create issue templates according to Github docs: https://docs.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository

We should have at least two templates:
Bug Report:

• Label with "bug", "triage"
• Have Steps to Reproduce, Expected Results, Actual Results, Environment (eg. version found in) sections

Feature Request:

• Label with "feature request", "triage"
• Have a section for "Definition of Done".

Script session allowing the existing calls, DB ripped out. Not the API side.

Instead of storing notebooks in the workspace data, use the file system.

Clean up existing java code base, separating out packages for oss. Leave in existing repo for this step.

Not in a separate repo, but separate artifact, removing dependencies that shouldn't be there.

Construct snapshot. No logic changes.

Should integrate with the build system in the repo as well.

Research task to investigate which logger to use (fishlib, or sfl4j)

Applies to aggregation, treetables, rollups.

Precursor to #5 .

We need a git structure / workflow that focuses on allowing developers to be productive. Build/CI concerns apply.

I've been prototyping out some workflows in demo-app. I suggest:

• Immutable annotated release tags, format v_<major>.<minor>.<patch>
• Only release tags can be prefixed with v_
• All merges to main go through PRs.
• PRs to main can only be merged when green.
• (TODO:) Should PRs builds be based on a post-merge ref, or a pre-merge ref?
• All initial feature releases (ie, v_<major>.<minor>.0) are tagged from main.
• Branches off of main meant to be merged back into main should be named feature/<f>
• Release branches have the format release/<major>.<minor>.x.
• All patch work is done against the tip of the oldest supported release branch (which, barring major security patches, should always be the latest release)
• Patch work to be merged into a release branch should have the format hotfix/<x>
• Patch releases hit each subsequent release branch and create their own releases before being merged forward into main
• Versioning happens automatically
• Commit message format? Tagging in commit message? (Potentially, mandating referencing any ticket numbers?)

This will also include detangling from fishlib comm which shares its scheduler, and probably switching to some OSS scheduler.

this is the body

clients must be able to subscribe to all export status changes

• new subscriptions must refresh all outstanding exports
• the refresh + update stream must be consistent

Part to interpret columns and formulas.
Port function libraries.
Retarget new version of java parser.

SessionState is relatively complicated due to all of the ways that the user can interact with exports.

Exports:

• have dependencies
• may be defined out of order (cannot guarantee ordering in grpc)
• may have clean-up tasks when released
• can throw exceptions in error handlers
• can throw exceptions in the exporting callable
• users can cancel/release at any time

Unit tests have been deferred in favor of getting a proof of concept going, but these tests are extremely important.

Remove the parts from the Web UI that are not needed in the MVP of this project. Eg.

• Login screen
• Tabs/dashboard switching
• New tab screen
• Query monitor
• User info in the side bar

Set up a build entry point that builds the whole gradle/java project. As components are added, they should be added to the build file/system we use.

Should have support for building the project, running all tests (including enforcing the style guide, see #6 .

• Barrage serialization
• Convert to BarrageMessageProducer automatically (no need to export an existing table again)
• Must properly manage liveness
• Multiple subscriptions on the same table are allowed without additional exports.
• Out of band Subscription Updates (web is server-streaming only)
• Aimed at Web UI (i.e. no need for ReplicatedTable in this issue)

this is a test