You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
91 lines
3.2 KiB
91 lines
3.2 KiB
# Roadmap
|
|
|
|
This document describes currently planned features and events related to the
|
|
dehub project. It's intention is to help prioritize work. There are no dates
|
|
set, only a sequence of milestones and the requirements to hit them.
|
|
|
|
## Milestone: Publicize project
|
|
|
|
Must be able to feel good about showing the project publicly, as well as be able
|
|
to accept help from people asking to help.
|
|
|
|
* Figure out commit range syntax, use that everywhere.
|
|
* Tutorials
|
|
* Maybe move external host?
|
|
|
|
## Milestone: IPFS support
|
|
|
|
* Big ol' question mark on this one.
|
|
|
|
## Milestone: Versions
|
|
|
|
* Tag commits
|
|
* Add dehub version to the SPEC, make binary aware of it
|
|
* Figure out a release system?
|
|
|
|
## Milestone: Checkpoints
|
|
|
|
* Ability to set change commits as being a "checkpoint", so that they mark a new
|
|
root commit. A couple of considerations:
|
|
- Only a checkpoint on the main branch should be considered when determining
|
|
the project "root".
|
|
- Must be a flag on change commits, to allow hard-forks of projects where
|
|
the config file is completely replaced.
|
|
- Not sure if it should be subject to ACL or not.
|
|
|
|
## Milestone: Minimal plugin support
|
|
|
|
* SPEC and implement. Things which should be pluggable, initially:
|
|
* Conditions
|
|
* Signifiers
|
|
* Filters
|
|
* Commits???
|
|
|
|
## Milestone: Minimal notifications support
|
|
|
|
* Some way to store notification settings locally, and run a command which shows
|
|
a sequence of events since the last time you ran it.
|
|
* The command should keep a history of all of its outputs, and allow the
|
|
user to see that history (in case they run the command, then clear the
|
|
output by accident).
|
|
* The user should be able to specifically get notifications on threads
|
|
they're a part of, threads by branch name pattern, files by path pattern,
|
|
and keywords in commit messages.
|
|
|
|
# Misc Polish
|
|
|
|
These tasks aren't necessarily scheduled for any particular milestone, but they
|
|
are things that could use doing anyway.
|
|
|
|
* Config validation. Every interface used by the config should have a
|
|
`Validate() error` method, and Config itself should as well.
|
|
|
|
* Maybe coalesce the `accessctl`, `fs`, and `sigcred` packages back into the
|
|
root "dehub" package.
|
|
|
|
* Polish all error messages. A good error message has the following qualities:
|
|
* If wrapping an error which was returned from a sub-call:
|
|
* Uses `fmt.Errorf` with the `%w` format directive at the end.
|
|
* Phrased as if the sentence starts with the word "while", e.g. "opening
|
|
file: %w".
|
|
* Only includes information the caller of that function/method couldn't
|
|
already know.
|
|
|
|
* Polish commands
|
|
* New flag system, some kind of interactivity support (e.g. user doesn't
|
|
specify required argument, give them a prompt on the CLI to input it
|
|
rather than an error). This is partially done, in that a new flag system
|
|
has been started. Needs further work.
|
|
|
|
* Review flags:
|
|
* probably make some of them into positional arguments
|
|
* add flag shortcuts
|
|
* document everything better.
|
|
|
|
* POSIX compatible-ish flags?
|
|
|
|
* Possibly save state locally in order to speed things along, such as
|
|
"account id" which probably isn't going to change often for a user.
|
|
|
|
* More/better tests
|
|
* Commits need much better test coverage.
|
|
|