2023-02-21 launch check in¶
General check in¶
Users & Permissions¶
- There’s a open PR with rest of pending items
- If we want to change UX as per Kriti’s comments, won’t take long
- pending confirmation
- let’s go ahead with UX changes
- Hopefully merged today or tomorrow
- Docs for this are currently assigned to Kriti;
- Don’t include unconfirmed tables issue #2520
- There’s a PR – pending review;
Installation & Deployment¶
- SSL wasn’t working, but it’s fixed
- PR is in, not quite working, but it’ll be sorted by tomorrow
- Mukesh’s approach is better
- that will make deployment work on a server with a domain
- next priority: deployment type 2
- connect existing database
- not very difficult
- library.mathesar.org will be used for testing deployment types
- static files not loading issue was breaking Docker image, that’s fixed
masterbuilds Docker image that functions
- Usability testing: seems to be going well.
- We can work on this after deployment type 2
- Deployment type 3:
- Mostly should work, needs either documentation on environment variables, or convenience scripts to wrap commands in proper environment (e.g., read from .env file)
- Load testing has multiple issues
- When initializing multiple users at once, demo server doesn’t return requests
- Front end issues are further out in the queue
- 404 page PR is submitted
- Integrating documentation is happening today
- Integrating into website
- Documenting type 2 and 3 deployments
- Ghislaine working on styling
- could integrate feedback from usability testers
- PRs are in for all blocking issues
- People should be reviewing today or tomorrow
- Sean opened a PR over the weekend.
- The releases exist, but
- We should delete them
- Merge the upgrades frontend PR #2514,
- Change POST request to GET
- Make some new releases,
- Make sure it works through manual QA.
- Migrations are reset
- Create and publish first release
- The HN post is in the works
Priorities per person¶
- Reviewing #2520
- Community work
- QA for Users and Permissions
- Testing deployment type 1 with SSL
- Deployment type 2
- Propose release process
- Implement deployment usability testing fixes as needed
- Website bio double-check
- Rewrite upgrade endpoint from GET to POST in caddyfile
- Demo bottleneck hunting
- Style Wiki and Documentation
- Update bios on website
- Alternative design for CTA
- Table rename prompt design
- Keep people unblocked
- Plan for QA and docs
- Write README, HN post, etc.
- Get the analytics PR #2513 merged into the frontend codebase
- Start working on Deployment Type 3 work
- Log more analytic events
- Review and merge upgrades PR
- Get users & permissions PR merged - fix review comments if any
- Review other launch PRs
- Avoid merging / worrying about PRs not involved with launch
- General usability testing
- Docs for users and permissions
- QA for users and permissions
- PR review for Pavish/Rajat
- Live demo usability improvements
Testing Docker images, Github Releases¶
Summary: Follow up on Brent’s email, decide on next steps
- Process proposed in email seems very bureaucratic
- Big picture: We need to know our master branch produce deployments that function.
- How often do we need to test that install.sh works?
- Should we test on every PR?
- Setting up CI for this would be tricky
- Should we test before every release?
- If we identify problems, it could take some time to diagnose and fix if the problem was introduced a long time before.
- Brent is interested in a using a separate Docker repo (not a separate GitHub repo). We might need separate images for separate deployment types
- Kriti: I don’t think manually testing every day before release is a priority. And I don’t think setting up automated testing is a priority right now either.
- Main thing we need to discuss right now: What’s the process for cutting a release?
- Do we really need a separate Docker repo to test the releaes?
- We could use a separate tag in the same Docker repo.
- We have the non-pro version of Docker. It’s not great for managing tags.
- Brent: We should make it so that install.sh takes a tag name as an argument. Then the docs instructions would tell users to run install.sh with a tag name that we manually set into the docs content.
- Dom: we’ll need to consider how the upgrade process works with Watchtower, may not work unless we use a consistent tag for latest version (rather than version number based tags).
- Lots of complexity to consider, can’t resolve now.
- Next step: Brent will write a wiki page proposing a step-by-step process for how to cut a release.
- We’ll discuss once that’s ready